hi, folks
I have client and server using nfsv3. The kernels are all 4.16-rc3.
In client I mount a partition or a disk formatted in xfs/ext4 in
/nfstest. It seems there is someting wrong with inheritance of sgid. I
try the following operations in the client.
> [root@localhost ]#id user1
> uid=1003(user1) gid=1006(testgroup1)
groups=1006(testgroup1),1007(testgroup2)
> [root@localhost ]# mount -t nfs -o vers=3 -o noac
192.168.56.9:/data/nfstest /mnt/test/
> [root@localhost ]# cd /mnt/test/
> [root@localhost ]# mkdir mainsub
> [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
> [root@localhost ]# chown user1:testgroup1 mainsub/
> # chmod 2775 mainsub/
> [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
> [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
> [root@localhost ]# ls -l mainsub/
> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
> drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
The subdir2 losts SGID. But if the same operations are applied in the
xfs or ext4 directedly, the SGID could be interited normally.
> [root@localhost ]# ls -l mainsub/
> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
Is this a bug of NFSv3?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
Clear SGID bit when setting file permissions
It seems this patch will clear the nfs sgid. Should we keep it?
Xinyu Lu
On Wed, Apr 25, 2018 at 02:03:20PM +0800, Lu Xinyu wrote:
> hi, folks
>
>
> I have client and server using nfsv3. The kernels are all 4.16-rc3.
> In client I mount a partition or a disk formatted in xfs/ext4 in
> /nfstest. It seems there is someting wrong with inheritance of sgid. I
> try the following operations in the client.
> > [root@localhost ]#id user1
> > uid=1003(user1) gid=1006(testgroup1)
> groups=1006(testgroup1),1007(testgroup2)
> > [root@localhost ]# mount -t nfs -o vers=3 -o noac
> 192.168.56.9:/data/nfstest /mnt/test/
> > [root@localhost ]# cd /mnt/test/
> > [root@localhost ]# mkdir mainsub
> > [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
> > [root@localhost ]# chown user1:testgroup1 mainsub/
> > # chmod 2775 mainsub/
> > [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
> > [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
> > [root@localhost ]# ls -l mainsub/
> > drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
> > drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
>
>
> The subdir2 losts SGID. But if the same operations are applied in the
> xfs or ext4 directedly, the SGID could be interited normally.
>
> > [root@localhost ]# ls -l mainsub/
> > drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
> > drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
>
> Is this a bug of NFSv3?
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
>
>
> Clear SGID bit when setting file permissions
>
> It seems this patch will clear the nfs sgid. Should we keep it?
Just searching for that commit id.... It looks like this was fixed by
ext4 by a3bb2d5587521eea6dab2d05326abb0afb460abd "ext4: Don't clear SGID
when inheriting ACLs". And there are similar patches for a bunch of
other filesystems.
--b.
>
>
> Xinyu Lu
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,Bruce
On 20180501 04:16, J. Bruce Fields wrote:
> On Wed, Apr 25, 2018 at 02:03:20PM +0800, Lu Xinyu wrote:
>> hi, folks
>>
>>
>> I have client and server using nfsv3. The kernels are all 4.16-rc3.
>> In client I mount a partition or a disk formatted in xfs/ext4 in
>> /nfstest. It seems there is someting wrong with inheritance of sgid. I
>> try the following operations in the client.
>>> [root@localhost ]#id user1
>>> uid=1003(user1) gid=1006(testgroup1)
>> groups=1006(testgroup1),1007(testgroup2)
>>> [root@localhost ]# mount -t nfs -o vers=3 -o noac
>> 192.168.56.9:/data/nfstest /mnt/test/
>>> [root@localhost ]# cd /mnt/test/
>>> [root@localhost ]# mkdir mainsub
>>> [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
>>> [root@localhost ]# chown user1:testgroup1 mainsub/
>>> # chmod 2775 mainsub/
>>> [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
>>> [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
>>> [root@localhost ]# ls -l mainsub/
>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
>>> drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
>>
>>
>> The subdir2 losts SGID. But if the same operations are applied in the
>> xfs or ext4 directedly, the SGID could be interited normally.
>>
>>> [root@localhost ]# ls -l mainsub/
>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
>>
>> Is this a bug of NFSv3?
>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
>>
>>
>> Clear SGID bit when setting file permissions
>>
>> It seems this patch will clear the nfs sgid. Should we keep it?
>
> Just searching for that commit id.... It looks like this was fixed by
> ext4 by a3bb2d5587521eea6dab2d05326abb0afb460abd "ext4: Don't clear SGID
> when inheriting ACLs". And there are similar patches for a bunch of
> other filesystems.
>
> --b.
>
Thanks for reply.
The SGID will not be cleared on the xfs. However, when it mounts a nfs
the SGID will get lost. I think it is a NFS bug.
Xinyu Lu
On Mon, May 14, 2018 at 02:43:49PM +0800, Lu Xinyu wrote:
> Hi,Bruce
>
> On 20180501 04:16, J. Bruce Fields wrote:
> > On Wed, Apr 25, 2018 at 02:03:20PM +0800, Lu Xinyu wrote:
> >> hi, folks
> >>
> >>
> >> I have client and server using nfsv3. The kernels are all 4.16-rc3.
> >> In client I mount a partition or a disk formatted in xfs/ext4 in
> >> /nfstest. It seems there is someting wrong with inheritance of sgid. I
> >> try the following operations in the client.
> >>> [root@localhost ]#id user1
> >>> uid=1003(user1) gid=1006(testgroup1)
> >> groups=1006(testgroup1),1007(testgroup2)
> >>> [root@localhost ]# mount -t nfs -o vers=3 -o noac
> >> 192.168.56.9:/data/nfstest /mnt/test/
> >>> [root@localhost ]# cd /mnt/test/
> >>> [root@localhost ]# mkdir mainsub
> >>> [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
> >>> [root@localhost ]# chown user1:testgroup1 mainsub/
> >>> # chmod 2775 mainsub/
> >>> [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
> >>> [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
> >>> [root@localhost ]# ls -l mainsub/
> >>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
> >>> drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
> >>
> >>
> >> The subdir2 losts SGID. But if the same operations are applied in the
> >> xfs or ext4 directedly, the SGID could be interited normally.
> >>
> >>> [root@localhost ]# ls -l mainsub/
> >>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
> >>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
> >>
> >> Is this a bug of NFSv3?
> >>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
> >>
> >>
> >> Clear SGID bit when setting file permissions
> >>
> >> It seems this patch will clear the nfs sgid. Should we keep it?
> >
> > Just searching for that commit id.... It looks like this was fixed by
> > ext4 by a3bb2d5587521eea6dab2d05326abb0afb460abd "ext4: Don't clear SGID
> > when inheriting ACLs". And there are similar patches for a bunch of
> > other filesystems.
> >
> > --b.
> >
> Thanks for reply.
> The SGID will not be cleared on the xfs. However, when it mounts a nfs
> the SGID will get lost. I think it is a NFS bug.
Also, I should have noticed that the fixes I mentioned are already in
the kernel you're testing.
Maybe nfs or knfsd needed a corresponding fix. I can't remember if you
posted a network trace--that would help assign blame to the client or
the server side.
--b.
Looking at the problem more closely....
So the desired behavior is that the SGID bit gets cleared on an explicit
set of the acl, but not when the acl is merely inherited as part of file
creation?
If I understand correctly, in the NFSv3 case default acl inheritance is
done manually by the client, which queries the default acl, calculates
the inherited acl itself, and applies the result to the new file using a
setacl call to the server.
The server isn't capable of distinguishing this setacl call from any
other setacl call, so can't know that it should skip clearing the SGID
bit.
Andreas, do I have that right? Is this fixable?
--b.
On Tue, May 15, 2018 at 09:56:13AM +0800, Lu Xinyu wrote:
> On 20180514 22:32, J. Bruce Fields wrote:
> > On Mon, May 14, 2018 at 02:43:49PM +0800, Lu Xinyu wrote:
> >> Hi,Bruce
> >>
> >> On 20180501 04:16, J. Bruce Fields wrote:
> >>> On Wed, Apr 25, 2018 at 02:03:20PM +0800, Lu Xinyu wrote:
> >>>> hi, folks
> >>>>
> >>>>
> >>>> I have client and server using nfsv3. The kernels are all 4.16-rc3.
> >>>> In client I mount a partition or a disk formatted in xfs/ext4 in
> >>>> /nfstest. It seems there is someting wrong with inheritance of sgid. I
> >>>> try the following operations in the client.
> >>>>> [root@localhost ]#id user1
> >>>>> uid=1003(user1) gid=1006(testgroup1)
> >>>> groups=1006(testgroup1),1007(testgroup2)
> >>>>> [root@localhost ]# mount -t nfs -o vers=3 -o noac
> >>>> 192.168.56.9:/data/nfstest /mnt/test/
> >>>>> [root@localhost ]# cd /mnt/test/
> >>>>> [root@localhost ]# mkdir mainsub
> >>>>> [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
> >>>>> [root@localhost ]# chown user1:testgroup1 mainsub/
> >>>>> # chmod 2775 mainsub/
> >>>>> [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
> >>>>> [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
> >>>>> [root@localhost ]# ls -l mainsub/
> >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
> >>>>> drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
> >>>>
> >>>>
> >>>> The subdir2 losts SGID. But if the same operations are applied in the
> >>>> xfs or ext4 directedly, the SGID could be interited normally.
> >>>>
> >>>>> [root@localhost ]# ls -l mainsub/
> >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
> >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
> >>>>
> >>>> Is this a bug of NFSv3?
> >>>>
> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
> >>>>
> >>>>
> >>>> Clear SGID bit when setting file permissions
> >>>>
> >>>> It seems this patch will clear the nfs sgid. Should we keep it?
> >>>
> >>> Just searching for that commit id.... It looks like this was fixed by
> >>> ext4 by a3bb2d5587521eea6dab2d05326abb0afb460abd "ext4: Don't clear SGID
> >>> when inheriting ACLs". And there are similar patches for a bunch of
> >>> other filesystems.
> >>>
> >>> --b.
> >>>
> >> Thanks for reply.
> >> The SGID will not be cleared on the xfs. However, when it mounts a nfs
> >> the SGID will get lost. I think it is a NFS bug.
> >
> > Also, I should have noticed that the fixes I mentioned are already in
> > the kernel you're testing.
> >
> > Maybe nfs or knfsd needed a corresponding fix. I can't remember if you
> > posted a network trace--that would help assign blame to the client or
> > the server side.
>
> > 1031 86.468126816 192.168.56.2 192.168.56.4 NFS 222 V3 MKDIR Call (Reply In 1032), DH: 0x7918716d/subdir2
> > 1032 86.468825412 192.168.56.4 192.168.56.2 NFS 330 V3 MKDIR Reply (Call In 1031)
> > 1033 86.469002409 192.168.56.2 192.168.56.4 NFS 182 V3 GETATTR Call (Reply In 1034), FH: 0x7918716d
> > 1034 86.469185213 192.168.56.4 192.168.56.2 NFS 182 V3 GETATTR Reply (Call In 1033) Directory mode: 2775 uid: 1001 gid: 1002
> > 1035 86.469267903 192.168.56.2 192.168.56.4 NFSACL 186 V3 GETACL Call (Reply In 1036)
> > 1036 86.469520107 192.168.56.4 192.168.56.2 NFSACL 314 V3 GETACL Reply (Call In 1035)
> attr Directory mode: 2775 uid: 1001 gid: 1002
> > 1037 86.469584940 192.168.56.2 192.168.56.4 NFSACL 322 V3 SETACL Call (Reply In 1038)
> > 1038 86.469837540 192.168.56.4 192.168.56.2 NFSACL 186 V3 SETACL Reply (Call In 1037)
> attr Directory mode: 0775 uid: 1001 gid: 1002
> The SGID gets lost here. It occurs on server side.
Ugh, resending with Andreas's address spelled correctly.
On Tue, May 15, 2018 at 04:41:47PM -0400, J. Bruce Fields wrote:
> Looking at the problem more closely....
>
> So the desired behavior is that the SGID bit gets cleared on an explicit
> set of the acl, but not when the acl is merely inherited as part of file
> creation?
>
> If I understand correctly, in the NFSv3 case default acl inheritance is
> done manually by the client, which queries the default acl, calculates
> the inherited acl itself, and applies the result to the new file using a
> setacl call to the server.
>
> The server isn't capable of distinguishing this setacl call from any
> other setacl call, so can't know that it should skip clearing the SGID
> bit.
>
> Andreas, do I have that right? Is this fixable?
>
> --b.
>
> On Tue, May 15, 2018 at 09:56:13AM +0800, Lu Xinyu wrote:
> > On 20180514 22:32, J. Bruce Fields wrote:
> > > On Mon, May 14, 2018 at 02:43:49PM +0800, Lu Xinyu wrote:
> > >> Hi,Bruce
> > >>
> > >> On 20180501 04:16, J. Bruce Fields wrote:
> > >>> On Wed, Apr 25, 2018 at 02:03:20PM +0800, Lu Xinyu wrote:
> > >>>> hi, folks
> > >>>>
> > >>>>
> > >>>> I have client and server using nfsv3. The kernels are all 4.16-rc3.
> > >>>> In client I mount a partition or a disk formatted in xfs/ext4 in
> > >>>> /nfstest. It seems there is someting wrong with inheritance of sgid. I
> > >>>> try the following operations in the client.
> > >>>>> [root@localhost ]#id user1
> > >>>>> uid=1003(user1) gid=1006(testgroup1)
> > >>>> groups=1006(testgroup1),1007(testgroup2)
> > >>>>> [root@localhost ]# mount -t nfs -o vers=3 -o noac
> > >>>> 192.168.56.9:/data/nfstest /mnt/test/
> > >>>>> [root@localhost ]# cd /mnt/test/
> > >>>>> [root@localhost ]# mkdir mainsub
> > >>>>> [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
> > >>>>> [root@localhost ]# chown user1:testgroup1 mainsub/
> > >>>>> # chmod 2775 mainsub/
> > >>>>> [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
> > >>>>> [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
> > >>>>> [root@localhost ]# ls -l mainsub/
> > >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
> > >>>>> drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
> > >>>>
> > >>>>
> > >>>> The subdir2 losts SGID. But if the same operations are applied in the
> > >>>> xfs or ext4 directedly, the SGID could be interited normally.
> > >>>>
> > >>>>> [root@localhost ]# ls -l mainsub/
> > >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
> > >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
> > >>>>
> > >>>> Is this a bug of NFSv3?
> > >>>>
> > >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
> > >>>>
> > >>>>
> > >>>> Clear SGID bit when setting file permissions
> > >>>>
> > >>>> It seems this patch will clear the nfs sgid. Should we keep it?
> > >>>
> > >>> Just searching for that commit id.... It looks like this was fixed by
> > >>> ext4 by a3bb2d5587521eea6dab2d05326abb0afb460abd "ext4: Don't clear SGID
> > >>> when inheriting ACLs". And there are similar patches for a bunch of
> > >>> other filesystems.
> > >>>
> > >>> --b.
> > >>>
> > >> Thanks for reply.
> > >> The SGID will not be cleared on the xfs. However, when it mounts a nfs
> > >> the SGID will get lost. I think it is a NFS bug.
> > >
> > > Also, I should have noticed that the fixes I mentioned are already in
> > > the kernel you're testing.
> > >
> > > Maybe nfs or knfsd needed a corresponding fix. I can't remember if you
> > > posted a network trace--that would help assign blame to the client or
> > > the server side.
> >
> > > 1031 86.468126816 192.168.56.2 192.168.56.4 NFS 222 V3 MKDIR Call (Reply In 1032), DH: 0x7918716d/subdir2
> > > 1032 86.468825412 192.168.56.4 192.168.56.2 NFS 330 V3 MKDIR Reply (Call In 1031)
> > > 1033 86.469002409 192.168.56.2 192.168.56.4 NFS 182 V3 GETATTR Call (Reply In 1034), FH: 0x7918716d
> > > 1034 86.469185213 192.168.56.4 192.168.56.2 NFS 182 V3 GETATTR Reply (Call In 1033) Directory mode: 2775 uid: 1001 gid: 1002
> > > 1035 86.469267903 192.168.56.2 192.168.56.4 NFSACL 186 V3 GETACL Call (Reply In 1036)
> > > 1036 86.469520107 192.168.56.4 192.168.56.2 NFSACL 314 V3 GETACL Reply (Call In 1035)
> > attr Directory mode: 2775 uid: 1001 gid: 1002
> > > 1037 86.469584940 192.168.56.2 192.168.56.4 NFSACL 322 V3 SETACL Call (Reply In 1038)
> > > 1038 86.469837540 192.168.56.4 192.168.56.2 NFSACL 186 V3 SETACL Reply (Call In 1037)
> > attr Directory mode: 0775 uid: 1001 gid: 1002
> > The SGID gets lost here. It occurs on server side.
Hi Bruce,
On 15 May 2018 at 22:42, J. Bruce Fields <[email protected]> wrote:
> Ugh, resending with Andreas's address spelled correctly.
>
> On Tue, May 15, 2018 at 04:41:47PM -0400, J. Bruce Fields wrote:
>> Looking at the problem more closely....
>>
>> So the desired behavior is that the SGID bit gets cleared on an explicit
>> set of the acl, but not when the acl is merely inherited as part of file
>> creation?
ideally yes, but that's not achievable over NFSv3, only over NFSv4.
>> If I understand correctly, in the NFSv3 case default acl inheritance is
>> done manually by the client, which queries the default acl, calculates
>> the inherited acl itself, and applies the result to the new file using a
>> setacl call to the server.
>>
>> The server isn't capable of distinguishing this setacl call from any
>> other setacl call, so can't know that it should skip clearing the SGID
>> bit.
>>
>> Andreas, do I have that right? Is this fixable?
Yes, I believe that's exactly what's happening.
Thanks,
Andreas
>> --b.
>>
>> On Tue, May 15, 2018 at 09:56:13AM +0800, Lu Xinyu wrote:
>> > On 20180514 22:32, J. Bruce Fields wrote:
>> > > On Mon, May 14, 2018 at 02:43:49PM +0800, Lu Xinyu wrote:
>> > >> Hi,Bruce
>> > >>
>> > >> On 20180501 04:16, J. Bruce Fields wrote:
>> > >>> On Wed, Apr 25, 2018 at 02:03:20PM +0800, Lu Xinyu wrote:
>> > >>>> hi, folks
>> > >>>>
>> > >>>>
>> > >>>> I have client and server using nfsv3. The kernels are all 4.16-rc3.
>> > >>>> In client I mount a partition or a disk formatted in xfs/ext4 in
>> > >>>> /nfstest. It seems there is someting wrong with inheritance of sgid. I
>> > >>>> try the following operations in the client.
>> > >>>>> [root@localhost ]#id user1
>> > >>>>> uid=1003(user1) gid=1006(testgroup1)
>> > >>>> groups=1006(testgroup1),1007(testgroup2)
>> > >>>>> [root@localhost ]# mount -t nfs -o vers=3 -o noac
>> > >>>> 192.168.56.9:/data/nfstest /mnt/test/
>> > >>>>> [root@localhost ]# cd /mnt/test/
>> > >>>>> [root@localhost ]# mkdir mainsub
>> > >>>>> [root@localhost ]# setfacl -d -m u:user2:rwx mainsub/
>> > >>>>> [root@localhost ]# chown user1:testgroup1 mainsub/
>> > >>>>> # chmod 2775 mainsub/
>> > >>>>> [root@localhost ]# runuser -u user1 -g testgroup1 mkdir mainsub/subdir1
>> > >>>>> [root@localhost ]# runuser -u user1 -g testgroup2 mkdir mainsub/subdir2
>> > >>>>> [root@localhost ]# ls -l mainsub/
>> > >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir1
>> > >>>>> drwxrwxr-x+ 2 user1 testgroup1 4096 Mar 6 22:50 subdir2
>> > >>>>
>> > >>>>
>> > >>>> The subdir2 losts SGID. But if the same operations are applied in the
>> > >>>> xfs or ext4 directedly, the SGID could be interited normally.
>> > >>>>
>> > >>>>> [root@localhost ]# ls -l mainsub/
>> > >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir1
>> > >>>>> drwxrwsr-x+ 2 user1 testgroup1 4096 Mar 6 22:55 subdir2
>> > >>>>
>> > >>>> Is this a bug of NFSv3?
>> > >>>>
>> > >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=073931017b49d9458aa351605b43a7e34598caef
>> > >>>>
>> > >>>>
>> > >>>> Clear SGID bit when setting file permissions
>> > >>>>
>> > >>>> It seems this patch will clear the nfs sgid. Should we keep it?
>> > >>>
>> > >>> Just searching for that commit id.... It looks like this was fixed by
>> > >>> ext4 by a3bb2d5587521eea6dab2d05326abb0afb460abd "ext4: Don't clear SGID
>> > >>> when inheriting ACLs". And there are similar patches for a bunch of
>> > >>> other filesystems.
>> > >>>
>> > >>> --b.
>> > >>>
>> > >> Thanks for reply.
>> > >> The SGID will not be cleared on the xfs. However, when it mounts a nfs
>> > >> the SGID will get lost. I think it is a NFS bug.
>> > >
>> > > Also, I should have noticed that the fixes I mentioned are already in
>> > > the kernel you're testing.
>> > >
>> > > Maybe nfs or knfsd needed a corresponding fix. I can't remember if you
>> > > posted a network trace--that would help assign blame to the client or
>> > > the server side.
>> >
>> > > 1031 86.468126816 192.168.56.2 192.168.56.4 NFS 222 V3 MKDIR Call (Reply In 1032), DH: 0x7918716d/subdir2
>> > > 1032 86.468825412 192.168.56.4 192.168.56.2 NFS 330 V3 MKDIR Reply (Call In 1031)
>> > > 1033 86.469002409 192.168.56.2 192.168.56.4 NFS 182 V3 GETATTR Call (Reply In 1034), FH: 0x7918716d
>> > > 1034 86.469185213 192.168.56.4 192.168.56.2 NFS 182 V3 GETATTR Reply (Call In 1033) Directory mode: 2775 uid: 1001 gid: 1002
>> > > 1035 86.469267903 192.168.56.2 192.168.56.4 NFSACL 186 V3 GETACL Call (Reply In 1036)
>> > > 1036 86.469520107 192.168.56.4 192.168.56.2 NFSACL 314 V3 GETACL Reply (Call In 1035)
>> > attr Directory mode: 2775 uid: 1001 gid: 1002
>> > > 1037 86.469584940 192.168.56.2 192.168.56.4 NFSACL 322 V3 SETACL Call (Reply In 1038)
>> > > 1038 86.469837540 192.168.56.4 192.168.56.2 NFSACL 186 V3 SETACL Reply (Call In 1037)
>> > attr Directory mode: 0775 uid: 1001 gid: 1002
>> > The SGID gets lost here. It occurs on server side.
On Tue, May 15, 2018 at 11:47:10PM +0200, Andreas Gruenbacher wrote:
> Hi Bruce,
>
> On 15 May 2018 at 22:42, J. Bruce Fields <[email protected]> wrote:
> > Ugh, resending with Andreas's address spelled correctly.
> >
> > On Tue, May 15, 2018 at 04:41:47PM -0400, J. Bruce Fields wrote:
> >> Looking at the problem more closely....
> >>
> >> So the desired behavior is that the SGID bit gets cleared on an explicit
> >> set of the acl, but not when the acl is merely inherited as part of file
> >> creation?
>
> ideally yes, but that's not achievable over NFSv3, only over NFSv4.
>
> >> If I understand correctly, in the NFSv3 case default acl inheritance is
> >> done manually by the client, which queries the default acl, calculates
> >> the inherited acl itself, and applies the result to the new file using a
> >> setacl call to the server.
> >>
> >> The server isn't capable of distinguishing this setacl call from any
> >> other setacl call, so can't know that it should skip clearing the SGID
> >> bit.
> >>
> >> Andreas, do I have that right? Is this fixable?
>
> Yes, I believe that's exactly what's happening.
Well, we can't back out the CVE fix, so I think just living with this
behavior (the SGID being cleared sometimes when it didn't need to be) is
our least bad option. NFSv4 has the protocol we need to get this right,
and doesn't have this bug.
--b.