使用環境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系統目錄的權限，會存在權限風險