docker 非root用户修改mount到容器的文件出现“Operation not permitted

使用环境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系统目录的权限，会存在权限风险