Ah, maybe you're just trying to copy the NFS namespace and cross the
referral, not actually create a new referral. In that case - yes,
perhaps
this needs a fixup. We might look at how rsync crosses other
mountpoints,
because I think the same problem would exist. You'd want rsync to
create
the directory with the attributes of the root of the mounted filesystem,
not
the mountpoint.
Ben
On 4 Sep 2020, at 14:20, Benjamin Coddington wrote:
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
