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