* SGID loss with nfsv3 @ 2018-04-25 6:03 Lu Xinyu 2018-04-30 20:16 ` J. Bruce Fields 0 siblings, 1 reply; 8+ messages in thread From: Lu Xinyu @ 2018-04-25 6:03 UTC (permalink / raw) To: linux-nfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: SGID loss with nfsv3 2018-04-25 6:03 SGID loss with nfsv3 Lu Xinyu @ 2018-04-30 20:16 ` J. Bruce Fields 2018-05-14 6:43 ` Lu Xinyu 0 siblings, 1 reply; 8+ messages in thread From: J. Bruce Fields @ 2018-04-30 20:16 UTC (permalink / raw) To: Lu Xinyu; +Cc: linux-nfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: SGID loss with nfsv3 2018-04-30 20:16 ` J. Bruce Fields @ 2018-05-14 6:43 ` Lu Xinyu 2018-05-14 14:32 ` J. Bruce Fields 0 siblings, 1 reply; 8+ messages in thread From: Lu Xinyu @ 2018-05-14 6:43 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-nfs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: SGID loss with nfsv3 2018-05-14 6:43 ` Lu Xinyu @ 2018-05-14 14:32 ` J. Bruce Fields [not found] ` <5b6540f4-f744-5e51-c32f-c8809fbfed81@cn.fujitsu.com> 0 siblings, 1 reply; 8+ messages in thread From: J. Bruce Fields @ 2018-05-14 14:32 UTC (permalink / raw) To: Lu Xinyu; +Cc: linux-nfs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <5b6540f4-f744-5e51-c32f-c8809fbfed81@cn.fujitsu.com>]
* Re: SGID loss with nfsv3 [not found] ` <5b6540f4-f744-5e51-c32f-c8809fbfed81@cn.fujitsu.com> @ 2018-05-15 20:41 ` J. Bruce Fields 2018-05-15 20:42 ` J. Bruce Fields 0 siblings, 1 reply; 8+ messages in thread From: J. Bruce Fields @ 2018-05-15 20:41 UTC (permalink / raw) To: Lu Xinyu; +Cc: linux-nfs, fnst-xmlinux, agreunba 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: SGID loss with nfsv3 2018-05-15 20:41 ` J. Bruce Fields @ 2018-05-15 20:42 ` J. Bruce Fields 2018-05-15 21:47 ` Andreas Gruenbacher 0 siblings, 1 reply; 8+ messages in thread From: J. Bruce Fields @ 2018-05-15 20:42 UTC (permalink / raw) To: Lu Xinyu; +Cc: linux-nfs, fnst-xmlinux, agruenba 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: SGID loss with nfsv3 2018-05-15 20:42 ` J. Bruce Fields @ 2018-05-15 21:47 ` Andreas Gruenbacher 2018-05-15 22:05 ` J. Bruce Fields 0 siblings, 1 reply; 8+ messages in thread From: Andreas Gruenbacher @ 2018-05-15 21:47 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Lu Xinyu, Linux NFS Mailing List, fnst-xmlinux 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: SGID loss with nfsv3 2018-05-15 21:47 ` Andreas Gruenbacher @ 2018-05-15 22:05 ` J. Bruce Fields 0 siblings, 0 replies; 8+ messages in thread From: J. Bruce Fields @ 2018-05-15 22:05 UTC (permalink / raw) To: Andreas Gruenbacher; +Cc: Lu Xinyu, Linux NFS Mailing List, fnst-xmlinux 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-05-15 22:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-25 6:03 SGID loss with nfsv3 Lu Xinyu
2018-04-30 20:16 ` J. Bruce Fields
2018-05-14 6:43 ` Lu Xinyu
2018-05-14 14:32 ` J. Bruce Fields
[not found] ` <5b6540f4-f744-5e51-c32f-c8809fbfed81@cn.fujitsu.com>
2018-05-15 20:41 ` J. Bruce Fields
2018-05-15 20:42 ` J. Bruce Fields
2018-05-15 21:47 ` Andreas Gruenbacher
2018-05-15 22:05 ` J. Bruce Fields
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.