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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
