Re: Wrong mode bits in stat of NFSv4 referral directories.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I don't understand how the client can create a directory that can be a
referral.  Doesn't the directory have to be a mountpoint on the server?

I don't think that rsync can copy a namespace that contains refferal mounts
from the client side, but maybe I am really misunderstanding things..

Ben

On 4 Sep 2020, at 14:09, Pradeep wrote:

Thanks Benjamin. Looks like it is added as part of commit
72de53ec4bca39c26709122a8f78bfefe7b6bca4 by Bryan Schumaker.

Given that neither chmod nor readdir traverses the referral mount
points, wouldn't this be an issue to return mode bits as 0555?
The issue I see is with rsync. rsync first creates the directory and
calls chmod. If this directory happens to be a referral mount, then
chmod fails because the user doesn't have write access (0555).

Thanks

On Fri, Sep 4, 2020 at 10:15 AM Benjamin Coddington <bcodding@xxxxxxxxxx> wrote:

Probably in nfs_fixup_secinfo_attributes(), and looks deliberate. I'm not sure about the reasoning behind it, though. Maybe it's to clarify that you
can't traverse this directory.

Ben

On 4 Sep 2020, at 12:57, Pradeep wrote:

Just to add, if you look at packet 100 (READDIR response) in tcpdump, the mode bits are set to 0755. But what is displayed by "ls" is 0555.
I'm trying to figure out where that one bit gets lost.

On Fri, Sep 4, 2020 at 8:55 AM Pradeep <pradeepthomas@xxxxxxxxx> wrote:

Hello,

I'm seeing an issue where stat (and ls) reports wrong mode bits on
referral directories. Actual permissions are 755; but Linux client
displays 555. This causes some operations like setattr (chmod) to
fail. Traversing to the directory fixes the issue.

Kernel version : 5.8.6-2.el7.elrepo.x86_64

[nfstest@centos77 ~]$ mkdir /mnt/nfsh1/dir.{1..5}
[nfstest@centos77 ~]$ ls -l /mnt/nfsh1
total 3
dr-xr-xr-x. 2 nfstest wheel 2 Sep  3 17:55 dir.1
drwxr-xr-x. 2 nfstest wheel 2 Sep  3 17:55 dir.2
dr-xr-xr-x. 2 nfstest wheel 2 Sep  3 17:55 dir.3
dr-xr-xr-x. 2 nfstest wheel 2 Sep  3 17:55 dir.4
dr-xr-xr-x. 2 nfstest wheel 2 Sep  3 17:55 dir.5
[nfstest@centos77 ~]$ stat /mnt/nfsh1/dir.1
  File: ‘/mnt/nfsh1/dir.1’
Size: 2 Blocks: 1 IO Block: 1048576 directory
Device: 30h/48d Inode: 3940649673949864  Links: 2
Access: (0555/dr-xr-xr-x) Uid: ( 2000/ nfstest) Gid: ( 10/ wheel)
Context: system_u:object_r:nfs_t:s0
Access: 2020-09-03 17:55:59.082327209 -0400
Modify: 2020-09-03 17:55:59.082327209 -0400
Change: 2020-09-03 17:55:59.082327209 -0400
 Birth: -
[nfstest@centos77 ~]$ ls /mnt/nfsh1/dir.1 <-- Try traversing into the
dir, see the mode bits in stat after traversal.
[nfstest@centos77 ~]$ stat /mnt/nfsh1/dir.1
  File: ‘/mnt/nfsh1/dir.1’
Size: 2 Blocks: 1 IO Block: 32768 directory
Device: 32h/50d Inode: 3940649673949864  Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 2000/ nfstest) Gid: ( 10/ wheel)
Context: system_u:object_r:nfs_t:s0
Access: 2020-09-03 17:55:59.082327209 -0400
Modify: 2020-09-03 17:55:59.082327209 -0400
Change: 2020-09-03 17:55:59.082327209 -0400
 Birth: -

Attached is the tcpdump for requests. It looks like the server sends
back correct attributes; but the client somehow is ignoring it. Any
ideas why?

Thanks,
Pradeep





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux