Details
-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Lustre 2.12.3
-
None
-
CentOS 7
-
2
-
9223372036854775807
Description
On a filesystem using nodemap with GID mapping, we have noticed that a user could change the GID of files to the squash_gid even though the user is not part of the squash_gid group. The behavior is described below and does affect at least Lustre 2.10 and Lustre 2.12.
Reproducer
1. configure two Lustre VMs and start lustre targets on one of them using llmount.sh, and mount the client on the other VM.
For us, the server VM is 192.168.123.40@tcp0 and the mapped Lustre client VM is 192.168.123.41@tcp0
2. Apply the following nodemap configuration on the server side:
+ lctl nodemap_add scg + lctl nodemap_modify --name scg --property map_mode --value gid_only + lctl nodemap_modify --name scg --property admin --value 0 + lctl nodemap_modify --name scg --property deny_unknown --value 1 + lctl nodemap_modify --name scg --property trusted --value 0 + lctl nodemap_add_range --name scg --range 192.168.123.41@tcp0 + lctl nodemap_add_idmap --name scg --idtype gid --idmap 59224:59224 + lctl nodemap_activate 1
3. On the client VM 192.168.123.41@tcp0, a user with a mapped primary GID (sthiell/59224) will work as expected: chgrp is not allowed to any group that the user is not part of (including nobody).
$ id uid=59224(sthiell) gid=59224(sthiell) groups=59224(sthiell),98003(sw_vasp),98008(sw_schrodinger),98009(sw_matlab),98013(sw_stata),99001(sh_users),99010(sh_sysadm),99011(sh_swadm) $ touch foo $ ls -l foo -rw-rw-r-- 1 sthiell sthiell 0 Jan 25 09:07 foo $ chgrp 123456 foo chgrp: changing group of 'foo': Operation not permitted $ chgrp nobody foo chgrp: changing group of 'foo': Operation not permitted
4. However, on the same client, if the user changes the primary GID, or has a primary GID by default that is NOT mapped by nodemap, chgrp is allowed to any unmapped group:
$ newgrp sw_schrodinger # not mapped $ id uid=59224(sthiell) gid=98008(sw_schrodinger) groups=98008(sw_schrodinger),59224(sthiell),98003(sw_vasp),98009(sw_matlab),98013(sw_stata),99001(sh_users),99010(sh_sysadm),99011(sh_swadm) $ ls -l foo -rw-rw-r-- 1 sthiell sthiell 0 Jan 25 09:07 foo $ chgrp 123456 foo $ ls -l foo -rw-rw-r-- 1 sthiell nobody 0 Jan 25 09:07 foo $ chgrp nobody foo $ ls -l foo -rw-rw-r-- 1 sthiell nobody 0 Jan 25 09:07 foo
You see that chgrp is always successful in that case but, hopefully, the group ends up to be the squashed_gid, so I think that the security implications are somehow limited. It is very annoying for permissions and accounting though, that is why I set the severity of this ticket to 2.
My current guess is that because the squashed_gid (nobody) is used as primary GID of the user, Lustre automatically thinks it is a valid group for the user, and chgrp then works for any unmapped GID (because squashed_gid will be used instead of any unmapped group).
What need to be fixed is that we should always block a user from using chgrp to the squashed_gid, explicitly or implicitly (for unmapped groups).
I tried to fix this problem myself today, with no luck so far. I added a condition to check for uc->uc_o_gid == nodemap->nm_squash_gid in old_init_ucred_common(), like in new_init_ucred() which seems to be handling the case for chgrp (CFS_SETGRP) – however I have not tested that specifically as we don’t use SSK nor Kerberos.
This issue might also be related to LU-9145, see Kit Westneat’s comments in https://review.whamcloud.com/#/c/30812/
