运行Docker的用户名空间是否已知存在安全风险？
我一直在使用DigitalOcean的Dokku图像在Ubuntu上玩Docker。 一切似乎都很好。 只要检查lxc-checkconfig的安装是如何完成的，我发现lxc-checkconfig报告User namespace: Disabled 。
本教程解释说，这是因为内核没有用CONFIG_USER_NS=y编译，因此可以通过重新编译来实现。
因为一切工作正常，我想知道是否有一些我错过了这个用户命名空间的东西，例如，安全的好处。
那么，为什么通过启用用户命名空间添加function呢？ 如果我保持禁用，有哪些风险或已知问题？
从0.7.3开始，Docker不使用用户名空间（还）。 因此，从安全的angular度来看，启用它并不会改变任何事情。
一旦用户命名空间代码（和相关的用户空间工具）稳定，Docker将使用它来提供额外的安全性。
正如您引用的文档所示，用户命名空间将允许“容器的根用户”。 这意味着容器内的根用户不一定会映射到容器外部的根用户（即在主机上）。 这样，一个进程可以在容器中以root身份运行，但实际上可以映射到外部的普通（非特权）用户。
将来，用户名空间也可能允许启动容器而不需要主机上的root权限; 但是由于容器设置中的许多步骤需要这些权限（例如，build立networking），所以这将需要一些时间。
正如“ 用户命名空间已经到达Docker！ ”（ Phil Estes ， ESTESP ）中详细介绍的那样，Docker 1.9 （2014年11月） 的实验分支将提供此function。 PR 12648 。
用户命名空间最重要的特性之一就是允许容器与主机系统有不同的uid和gid范围视图。
具体来说，一个进程（在我们的例子中，我们的容器内的进程）可以提供一组来自主机uid和gid空间的映射，以便当进程认为它正在运行为uid 0（通常称为“root”），它可能实际上是以uid 1000或10000，甚至34934322运行。这一切都取决于我们在用户名称空间内创build进程时提供的映射。当然，从安全angular度来看，这应该很清楚，这是一个很好的特性，因为它允许我们的容器继续以root权限运行，但是在主机上没有任何root权限 。
请参阅“ 实验：用户命名空间支持 ”文档页面（适用于来自experimental.docker.com的实验docker版本 ）。
docker daemon --userns-remap=default
请注意，在启用实验性用户命名空间的情况下运行Docker守护程序（如与主机（ --pid=host ，– --net=host等）共享命名空间）或其他容器时，某些标准Dockerfunction当前不兼容。
该用户映射能力现在是每个守护进程，而不是每个容器（这将需要一个Linux内核的演进，而不是在工作中）。 与主机共享名称空间（–pid = host，–net = host等）
最后：
由于需要通过提供的映射将Docker守护进程的本地caching中的层数据分离出来，所以一旦使用了带有用户命名空间的实验版本， graphics目录的根目录（默认是
/var/lib/docker）将会有一个与重新映射的根uid和gid相关的额外间接级别 。例如，如果我提供给
--userns-remap标志--userns-remap用户具有以ID10000开头的从属用户和组范围，则以该重新映射设置运行的所有映像和容器的graphics目录的根将驻留在/var/lib/docker/10000.10000。
如果您使用实验版本，但不提供用户名称空间重新映射，则当前内容将被迁移到/var/lib/docker/0.0以区分重新映射的图层内容。
答案是：没有用户namspace有潜在的风险。 我推断这从Ubuntu上的LXC这篇文章 ：
特权
容器pipe理工具必须以root用户权限运行。 一个名为lxc-setup的实用程序的目的是为工具提供所需的文件function，以允许非root用户以足够的权限运行这些工具。 然而，作为一个容器中的根不能被可靠地包含，这是不值得的。 因此，build议不要使用lxc-setup，并为LXCpipe理员提供所需的sudo权限。
>预计在下一个长期支持（LTS）版本中可用的用户命名空间将允许容器根用户的容纳，以及减less创build和pipe理容器所需的特权量。
对于确切的风险的答案并不完全清楚，但现在你知道在Ubuntu的下一个LTS中拥有用户命名空间将会有好处，我认为这将是2014年4月的14.04。
任何额外的信息，以改善答案是非常感激。