使用环境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 21 Dec 19 04:50 . drwxr-xr-x. 1 root root 74 Dec 18 06:40 .. -rw-r--r--. 1 root root 0 Dec 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# 1 5000 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 /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 .
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系统目录的权限，会存在权限风险
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。