SGID loss with nfsv3

SGID loss with nfsv3

[Lu Xinyu]

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

Re: SGID loss with nfsv3

[J. Bruce Fields]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SGID loss with nfsv3

[Lu Xinyu]

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

Re: SGID loss with nfsv3

[J. Bruce Fields]

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.

Re: SGID loss with nfsv3

[J. Bruce Fields]

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.

Re: SGID loss with nfsv3

[J. Bruce Fields]

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.

Re: SGID loss with nfsv3

[Andreas Gruenbacher]

Hi Bruce,

On 15 May 2018 at 22:42, J. Bruce Fields <bfields@fieldses.org> 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.

Re: SGID loss with nfsv3

[J. Bruce Fields]

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 <bfields@fieldses.org> 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.