我一直在使用DigitalOcean的Dokku图像在Ubuntu中玩Docker。一切似乎都很好。只需检查docker的安装方式，我就会发现lxc-checkconfig报告User namespace: Disabled。
This tutorial解释这是因为内核没有用CONFIG_USER_NS=y编译，所以可以通过重新编译来实现。
由于一切正常，我想知道是否有关于这个用户命名空间事物的遗漏，例如安全性好处。
那么，为什么通过启用用户名空间来添加功能？如果我禁用它会有什么风险或已知问题？
答案 0 :(得分：2)
截至0.7.3，Docker还没有使用用户命名空间。因此，从安全角度来看，启用它不会改变任何内容。
一旦用户名称空间代码（以及相关的用户空间工具）稳定，Docker就会使用它来提供额外的安全性。
如您引用的文档所示，用户命名空间将允许“容纳容器root用户”。这意味着容器中的root用户不一定会映射到容器之外的root用户（即在主机上）。这样，进程可以在容器中以root身份运行，但实际上映射到外部的普通（非特权）用户。
将来，用户名称空间也可能允许在不需要主机的root权限的情况下启动容器;但是需要一段时间，因为容器设置中的许多步骤都需要这些权限（例如，设置网络）。
答案 1 :(得分：1)
详见“User namespaces have arrived in Docker!”（Phil Estes，ESTESP），此will be available in the experimental branch of docker 1.9（2014年11月）。 PR 12648
用户命名空间的最重要的功能之一是它允许容器具有与主机系统不同的uid和gid范围视图。
具体来说，进程（在我们的例子中，我们的容器内的进程）可以从主机uid和gid空间提供一组映射，这样当进程认为它以uid 0运行时（通常称为uid 0） “root”），它实际上可能以uid 1000或10000，甚至34934322运行。这完全取决于我们在用户命名空间内创建进程时提供的映射。当然，应该很清楚，从安全角度来看，这是一个很棒的功能，因为它允许我们的容器继续以root权限运行，但实际上没有主机上的任何root权限。
有关详情，请参阅“Experimental: User namespace support”文档页面（适用于experimental docker build的experimental.docker.com）。
docker daemon --userns-remap=default
请注意，当运行启用了实验性用户命名空间的Docker守护程序时，某些标准Docker功能当前不兼容，例如与主机（--pid=host，--net=host等）或其他容器共享命名空间
那个用户映射能力现在是每个守护进程，而不是每个容器（这需要Linux内核演进，而不是工作，但不是）。 与主机共享命名空间（--pid = host， - network = host等）
最后：
由于需要通过提供的映射来隔离Docker守护程序的图层数据的本地缓存中的内容，因此一旦您使用具有用户名称空间的实验版本，图表目录的根目录（
/var/lib/dockerby默认情况下）将有一个额外的间接级别，它与重新映射的根uid和gid 相关。例如，如果我提供给
--userns-remap标志的重新映射用户具有以ID10000开头的从属用户和组范围，那么所有运行的图像和容器的图形目录的根目录重新映射设置将驻留在/var/lib/docker/10000.10000如果您使用实验性构建但未提供用户名称空间重新映射，则您的当前内容将迁移到/var/lib/docker/0.0，以将其与重新映射的图层内容区分开来。
答案 2 :(得分：0)
答案是：没有用户namspace存在潜在风险。我从这个article on LXC on Ubuntu推断出这个：
特权
必须使用root用户运行容器管理工具 特权。一个名为lxc-setup的实用程序是有意写的 为工具提供所需的文件功能 非root用户以足够的权限运行工具。但是，作为 容器中的root无法可靠地包含，但事实并非如此 值得的。因此建议不要使用lxc-setup和 为LXC管理员提供所需的sudo权限。
<强>＆GT;用户命名空间，预计在下一个Long中可用 术语支持（LTS）发布，将允许容纳容器 root用户，以及减少所需的权限数量 创建和管理容器。
确切风险的答案对我来说并不完全清楚，但是现在您知道在ubuntu的下一个LTS中拥有用户命名空间会有好处，我认为这是2014年4月的14.04。
非常感谢任何改善答案的额外信息。