Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     Pradeep <pradeepthomas@gmail.com>
Cc:     bjschuma@netapp.com, Trond.Myklebust@netapp.com,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: Wrong mode bits in stat of NFSv4 referral directories.
Date:   Fri, 04 Sep 2020 14:20:26 -0400
Message-ID: <A1BD3037-ED80-4D52-B6C8-6F837F2522E9@redhat.com>
In-Reply-To: <CAD8zhTD7mPjiUkRn_crywXDNP2kWGpMc8M4QFTG1T9eihuz9XQ@mail.gmail.com>
References: <CAD8zhTCZmZTosrtKbBatXo40Lt40OfzsZGw7tzHdcP4xo9rWCg@mail.gmail.com>
 <CAD8zhTDOZyhDnOqqO0uUVfscPFXj391frTEKT3dLu9rNZVNtzQ@mail.gmail.com>
 <CAD8zhTAA2c+cSNxDWwHnEa3-DTm8AEZKVMo7Xw9Wwpv8Wfsfzg@mail.gmail.com>
 <0226355B-58CD-4792-B7B9-B4447CC4FD7F@redhat.com>
 <CAD8zhTD7mPjiUkRn_crywXDNP2kWGpMc8M4QFTG1T9eihuz9XQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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@redhat.com> 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@gmail.com> 
>>> 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
>>