使用环境centos7 x86-64 内核版本4.19.9
docker使用非root用户启动,daemon.json配置文件内容如下:
# cat daemon.json { "userns-remap":"dockertest" }
映射的user和group均为如下值
dockertest:231072:65536
启动方式为
docker run -itd -v /mnt:/mnt centos:latest /bin/sh
进入容器,在/mnt目录下进行修改文件属性的操作,出现如下错误(此时容器中的user id=0)
# chmod 777 test.sh chmod: changing permissions of 'test.sh': Operation not permitted
解决思路
首先在host上关闭SELinux的MAC功能,排除干扰
# setenforce 0
查看容器init进程映射到root namespace的进程(pid=54958,即容器的/bin/sh进程)的capabilities,可以看到是有chown权限的(cap_fowner),但仍然无法修改文件的DAC属性。
# getpcaps 49202 Capabilities for `49202': = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
容器上查看该文件的信息可以看到文件的用户和组的id都是 65534 ,该UID被称为unmapped user id,定义在/proc/sys/kernel/overflowuid中,是默认的UID(GID)。
sh-4.2# ls -al total 0 drwxr-xr-x. 2 65534 65534 21 Dec 18 08:49 . drwxr-xr-x. 1 root root 29 Dec 18 06:40 .. -rw-r--r--. 1 65534 65534 0 Dec 18 08:49 test.sh
命名空间的root用户所拥有的权限主要看该命名空间所映射到root namespace的uid和gid的范围,在docker上查看init进程映射到root namespace的uid范围,可以看到根进程映射到231072,最大映射的uid为231072+65536。因此该容器拥有root namespace下uid为 [231072,231072+65536]范围内的资源操作权限
# cat /proc/1/uid_map 0 231072 65536
解决方法:
一种解决方法就是修改root namespace下/mnt的属性,让其成为容器中root 用户对应的uid,即231072
# chown 231073:231072 test.sh
容器内查看该文件,可以看到其变为了root:root,这样就可以修改test.sh的权限了
# ls -al total 0 drwxr-xr-x. 2 65534 65534 21 Dec 19 04:50 . drwxr-xr-x. 1 root root 74 Dec 18 06:40 .. -rw-r--r--. 1 root root 0 Dec 18 08:49 test.sh
根据上述配置,容器的root用户拥有root namespace下uid [231072,231072+65536]范围内的资源操作权限,因此也可以在root namespace下将test.sh修改为 [231072,231072+65536]的任意值,比如使用"chown 236072:236072 test.sh"将用户和组都修改为231072+5000=236072,可以看到test.sh的用户和组变为了5000:5000,此时同样在容器内部可以修改test.sh
sh-4.2# ls -al total 0 drwxr-xr-x. 2 65534 65534 21 Dec 19 04:50 . drwxr-xr-x. 1 root root 74 Dec 18 06:40 .. -rw-r--r--. 1 5000 5000 0 Dec 18 08:49 test.sh
当然也可以在docker run 的参数中使用--privileged,这样docker的不会创建新的user namespace,以系统root用户执行操作
- 当程序执行对文件(目录)的操作时,其进程的EUID必须与文件(目录)的EUID保持一致,上述的test.sh是由root namespace的root用户创建的,因此其EUID=0。查看容器init进程的信息,如下,其在root namespace中的EUID为231072,因此无法操作root namespace中EUID为0的文件,使用上述解决方法将其配置为相同的值就可以解决问题
[root@localhost mnt]# ps -ef|grep /bin/sh 231072 54958 54941 0 13:55 pts/0 00:00:00 /bin/sh
从上面可以看出,在有capabilities支持的系统上,一个进程对一个文件的操作需要看这个进程是具有这项能力(capabilities),其次需要看其是否有该文件的操作权限(effective user id)。下文参见capabilities,意思是说当一个进程访问文件的时候,进程的uid和gid会映射到初始的user namespace,来验证该程序是否有权限操作该文件;当一个程序获取到文件的uid和gid,文件的uid和gid会映射到程序所在的user namespace。
When a process accesses a file, its user and group IDs are mapped into the initial user namespace for the purpose of permission checking and assigning IDs when creating a file.
When a process retrieves file user and group IDs via stat(2), the IDs are mapped in the opposite direction, to produce values relative to the process user and group ID mappings.
TIPS:
- docker默认启动是不会创建user namespace的
- 如果需要把docker数据持久化,最好使用docker volumes的方式,bind mount由于需要有操作host系统目录的权限,会存在权限风险
所有评论(0)