Supplemental Group
Supplemental groups are regular Linux groups. When a process runs in Linux, it has a UID, a GID, and one or more supplemental groups. These attributes can be set for a container’s main process. The
supplementalGroups
IDs are typically used for controlling access to shared storage, such as NFS and GlusterFS, whereas fsGroup is used for controlling access to block storage, such as Ceph RBD and iSCSI.
On an OpenShift node:
On the NFS server:
The /opt/nfs/ export is accessible by UID 65534 and the group 5555. In general, containers should not run as root, so in this NFS example, containers which are not run as UID 65534 or are not members the group 5555 will not be able to access the NFS export.
Often, the SCC matching the pod does not allow a specific user ID to be specified, thus using supplemental groups is a more flexible way to grant storage access to a pod. For example, to grant NFS access to the export above, the group 5555 can be defined in the pod definition:
2. nfsnobody
当客户端访问NFS服务时,服务器会根据情况将客户端用户的身份映射成NFS匿名用户nfsnobody。nfsnobody是由NFS服务在系统中自动创建的一个程序用户账号,该账号不能用于登录系统,专门用作NFS服务的匿名用户账号
# id nfsnobody
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
所谓用户身份映射,是指当客户端访问NFS服务器时,会自动被视作服务器中的nfsnobody用户,并按照该用户的权限设置去执行操作。但是并非所有的客户端都会被映射为nfsnobody用户,在/etc/exports配置文件中提供了以下选项,以决定是否将NFS客户端映射为nfsnobody用户:
root_squash,当NFS客户端以root用户身份访问时,映射为NFS服务器的nfsnobody用户。
no_root_squash,当NFS客户端以root身份访问时,映射为NFS服务器的root用户,也就是要为超级用户保留权限。这个选项会留下严重的安全隐患,一般不建议采用。
all_squash,无论NFS客户端以哪种用户身份访问,均映射为NFS服务器的nfsnobody用户。
其中默认值是root_squash,即当客户端以root用户的身份访问NFS共享时,在服务器端会自动被映射为匿名账号nfsnobody。
下面将分几种情况分别予以说明
By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. In this way, all root-created files are owned by nfsnobody, which prevents uploading of programs with the setuid bit set.
If no_root_squash is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute.
3. root用户的身份映射
设置ACL规则赋予nfsnobody用户rwx权限。
`[root@Server ~]# setfacl -m u:nfsnobody:rwx /var/share``
然后在客户端重新挂载共享目录,并测试能否写入。
[root@Client ~]# umount /mnt/share
[root@Client ~]# mount -t nfs 192.168.80.10:/var/share /mnt/share
[root@Client ~]# touch /mnt/share/b.txt复制
可以看到此时客户端可以写入,并且所创建文件的所有者正是nfsnobody。
[root@Client ~]# ll /mnt/share/b.txt
-rw-r--r--. 1 nfsnobody nfsnobody 0 3月 21 07:39 /mnt/share/b.txt复制
1.
2.
由于客户端当前所使用的用户身份是root,默认情况下,当客户端访问NFS服务器时,在服务器端会将其用户身份映射为nfsnobody,所以在服务器端只要赋予nfsnobody用户对共享目录具有写入权限,那么客户端自然就可以写入了。
下面我们再验证一下no_root_squash设置项,即root用户不进行身份映射。
首先在服务器端修改配置文件/etc/exports,为/var/share共享目录添加no_root_squash选项。
[root@server ~]# vim /etc/exports #修改配置文件
/var/share *(rw,no_root_squash,sync)
[root@Server ~]# exportfs -arv #重新加载服务
exporting *:/var/share复制
然后去掉对共享目录/var/share所设置的ACL规则,取消nfsnobody用户对该目录的写入权限。[root@Server ~]# setfacl -b /var/share
最后在客户端重新挂载共享目录,并测试能否写入。
[root@Client ~]# umount /mnt/share
[root@Client ~]# mount -t nfs 192.168.80.10:/var/share /mnt/share
[root@Client ~]# touch /mnt/share/c.txt
[root@Client ~]# ll /mnt/share/c.txt
-rw-r--r--. 1 root root 0 4月 14 17:08 /mnt/share/c.txt复制
可以发现,此时客户端仍然是可以写入的。因为对于NFS服务器而言,访问共享目录的客户端就是服务器中的root用户,对共享目录具有完全权限。所以no_root_squash选项会产生很大的安全隐患,一般情况下都不建议采用。
4. 普通用户的身份映射
如果客户端所使用的用户身份不是root,而是一个普通用户,那么默认情况下在服务器端会将其视作其它用户(other)。下面在客户端以普通用户的身份继续进行测试。
首先在服务器端修改配置文件/etc/exports,将共享目录/var/share中的no_root_squash选项去掉,重新加载服务之后,再次通过设置ACL规则的方式赋予nfsnobody用户读写执行权限。
[root@server ~]# vim /etc/exports #修改配置文件
/var/share *(rw,sync)
[root@Server ~]# exportfs -arv #重新加载服务
exporting *:/var/share
#通过设置ACL赋予nfsnobody用户rwx权限
[root@Server ~]# setfacl -m u:nfsnobody:rwx /var/share复制
在客户端重新挂载共享,并测试以root用户身份可以正常写入。
[root@Client ~]# umount /mnt/share
[root@Client ~]# mount 192.168.80.10:/var/share /mnt/share
[root@Client ~]# touch /mnt/share/d.txt
[root@Client ~]# ll /mnt/share/d.txt
-rw-r--r--. 1 nfsnobody nfsnobody 0 4月 14 17:29 /mnt/share/d.txt复制
下面在客户端创建一个admin用户,并设置密码。
[root@Client ~]# useradd admin
[root@Client ~]# echo 123 | passwd --stdin admin复制
切换到admin用户身份,尝试向共享目录中写入文件,写入失败,但是可以读取目录中的内容。因而如果客户端是以普通用户的身份访问NFS共享,那么默认情况下在服务器端并不将其映射为nfsnobody,而是视作其他用户(other)。
[root@Client ~]# su - admin
[admin@Client ~]$ touch /mnt/share/e.txt
touch: 无法创建"/mnt/share/e.txt": 权限不够
[admin@Client ~]$ cat /mnt/share/e.txt复制
下面在服务器端继续修改配置文件/etc/exports,在共享设置中添加“all_squash”选项,将所有客户端用户均映射为nfsnobody。
[root@server ~]# vim /etc/exports #修改配置文件
/var/share *(rw,sync,all_squash)
[root@Server ~]# exportfs -arv #重新加载服务
exporting *:/var/share复制
然后在客户端再次重新挂载共享(具体操作从略),此时以admin用户身份就可以写入了,并且可以发现所创建文件的所有者同样是nfsnobody。
[admin@Client ~]$ touch /mnt/share/e.txt
[admin@Client ~]$ ll /mnt/share/e.txt
-rw-rw-r--. 1 nfsnobody nfsnobody 0 4月 14 17:37 /mnt/share/e.txt复制
5. 用户身份重叠
在使用NFS共享的过程中,有时还可能会遇到用户身份重叠的问题。所谓用户身份重叠,是指在NFS服务采用默认设置(用户身份映射选项为root_squash)时,如果在服务器端赋予某个用户对共享目录具有相应权限,而且在客户端恰好也有一个具有相同uid的用户,那么当在客户端以该用户身份访问共享时,将自动具有服务器端对应用户的权限。下面举例予以说明。
首先在服务器端将/var/share共享还原为默认设置,并且取消/var/share目录针对nfsnobody用户的ACL规则,具体操作从略。
假设服务器端存在一个名为teacher的用户账号,uid为1246,将该用户设置为共享目录的所有者。
[root@Server ~]# id teacher #查看teacher用户的身份信息`
uid=1246(teacher) gid=1246(teacher) 组=1246(teacher
#将teacher用户设置为/var/share目录的所有者
[root@Server ~]# chown teacher /var/share
[root@Server ~]# ll -d /var/share
drwxr-xr-x. 2 teacher root 45 4月 14 17:37 /var/share复制
下面在客户端进行操作。首先仍是重新挂载共享目录,然后将原先admin用户的uid也改为1246。
[root@Client ~]# usermod -u 1246 admin
[root@Client ~]# id admin
uid=1246(admin) gid=1002(admin) 组=1002(admin)复制
然后以admin用户身份测试能否对共享目录执行写入操作,发现可以正常写入,并且所创建文件的所有者是admin。
[root@Client ~]# su - admin
[admin@Client ~]$ touch /mnt/share/f.txt
[admin@Client ~]$ ll /mnt/share/f.txt
-rw-rw-r--. 1 admin admin 0 4月 14 17:47 /mnt/share/f.txt复制
在服务器端查看admin用户所创建的文件,发现所有者则是teacher。
[root@Server ~]# ll /var/share/f.txt
-rw-rw-r--. 1 teacher 1002 0 4月 14 17:47 /var/share/f.txt复制
这是因为对于Linux系统而言,区分不同用户的唯一标识就是uid,至于用户名只是为了方便人类理解。所以在系统层面,无论是teacher用户还是admin用户,只要他们的uid一样,就认为是同一个用户。但也正是因为这个原因,才会导致出现用户身份重叠的问题,对于NFS服务而言,这也是一个比较严重的安全隐患。
如何避免用户身份重叠呢?可以从以下两个方面着手:
一是在设置NFS共享时,建议采用“all_squash”选项,将所有客户端用户均映射为nfsnobody。这样就可以有效避免用户身份重叠的问题。
二是应严格控制NFS共享目录的系统权限,尽量不用为普通用户赋予权限。
Reference:
https://blog.51cto.com/yttitan/2406403
评论
