为什么在启动新容器时，Docker默认使用相同的用户和cgroup名称空间？

Question

为什么在启动新容器时，Docker默认使用相同的用户和cgroup名称空间？

我不明白为什么Docker不设置一个新的用户名称空间，这样容器中的root与主机上的root不一样。

特别是，由于其他一切都是名称空间的(除了cgroup)，默认情况下不完全隔离容器是没有意义的。

有人能澄清为什么默认情况下Docker不启用用户名称空间吗？

主机名称空间：

parallels@debian-gnu-linux-vm:~$ ls -la /proc/self/ns
total 0
dr-x--x--x 2 parallels parallels 0 Jan 30 17:29 .
dr-xr-xr-x 9 parallels parallels 0 Jan 30 17:29 ..
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 net -> net:[4026531957]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 pid -> pid:[4026531836]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 user -> user:[4026531837]
lrwxrwxrwx 1 parallels parallels 0 Jan 30 17:29 uts -> uts:[4026531838]

容器命名空间：

docker run -ti --rm debian:latest
root@210189a7a164:/# ls -la /proc/self/ns
total 0
dr-x--x--x 2 root root 0 Jan 30 16:30 .
dr-xr-xr-x 9 root root 0 Jan 30 16:30 ..
lrwxrwxrwx 1 root root 0 Jan 30 16:30 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 ipc -> 'ipc:[4026532287]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 mnt -> 'mnt:[4026532285]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 net -> 'net:[4026532290]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 pid -> 'pid:[4026532288]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Jan 30 16:30 uts -> 'uts:[4026532286]'

对于主机和容器，user和cgroup名称空间是相同的。

Answer 1

至于Docker决定默认不启用用户的具体情况，您可能需要询问Docker，但我可以提供一个可能的rational。

Docker的总体设计理念似乎是允许使用容器，同时尽量减少对开发工作流程的干扰和复杂。

在从底层主机挂载卷时，启用用户名称空间可能会导致文件/目录权限问题，因为容器中使用的uid/gid可能没有安装目录的权限。

当然，可以通过仔细管理这些权限来解决这一问题，但这是一种干扰。

用户名称空间可以作为一个选项，因此单个组织和用户仍然有可能启用它，只需要设置它。

值得注意的是，Docker还致力于启用“无根”Docker支持，这是一个实验性选项(更详细的这里 )，这将解决总体问题，确保没有容器(或守护进程本身)作为根用户运行。

Answer 2

这基本上是可用性和安全性之间的经典权衡。在CVE-2019-5736被报告为用户命名空间减轻后，我为开发人员桌面配置了它，几个月后我关闭了它。这使得使用主机卷变得非常困难。对于部署的云本机应用程序来说，这不是什么大问题，但如果您将docker用于诸如CI构建或sysadmin工具之类的开发目的，或者用于依赖大量主机文件的遗留应用程序，则这是一个巨大的问题。

使问题更加复杂的是，我是唯一有这个问题的人，当然，如果用户名称空间是默认的，那么情况就不会是这样了，但是这个特性直到docker 1.10才可用，到那时，更改默认将对现有用户造成太大的干扰。