当使用该命令unshare创建命名空间时，如果您不是主机中的 root 并创建除用户类型之外的任何命名空间，您将收到此错误：Operation not permitted.显然，以 root 身份运行将使其工作。
那么，如果unshare -n（取消共享网络命名空间）出现此错误，为什么unshare -Un（取消共享用户和网络命名空间）不会出现此错误？
我看到但不知道是否正确的第一个选项是所有名称空间实际上都与用户名称空间关联。如果您没有足够的权限，则无法将新的命名空间与其关联。但是当您创建用户命名空间时，您就获得了特权，这成为可能。
如果上述情况属实，我可以说每个进程都有一个用户名称空间，即使我从未明确将其创建为用户？这适用于其他名称空间吗？
编辑：正如评论中指出的，unshare -Un可能会给出相同的错误：operation not permitted。我使用 Ubuntu 20.04 进行测试，它启用了用户命名空间。我相信这就是区别。
答案1
因为为什么不呢？
除其他外，命名空间是一种沙箱机制。它们允许修改隔离域内的某些设置，而不必担心它们是否会影响系统的其余部分。
以挂载命名空间为例。挂载文件系统通常是一种特权操作：如果您可以挂载任意文件系统，您尤其可以挂载包含您选择的 set-user-id 可执行文件的文件系统，然后执行它，从而执行权限升级攻击。但是，在用户命名空间内启动 set-user-id 可执行文件只能增加其在该命名空间内的权限：用户命名空间内的根用户 ID 将映射到命名空间外的常规用户 ID，并且进程功能同样仅适用于资源从属于该命名空间。
如果没有用户命名空间，创建其他类型的命名空间可能会被利用以类似的方式进行权限升级。但是，当“权限”被限制在用户命名空间内时，就没有理由不允许它了——事实上，有一些这样的用例。用户命名空间不仅限制特权，还创造了定义特权-非特权边界的可能性之内命名空间，防止恶意进程完全逃离沙箱并接管沙箱本身。
LWN 文章操作中的命名空间，第 6 部分：有关用户命名空间的更多信息列出了一些用于非特权创建命名空间的可能应用程序：
通过隔离功能对命名空间的影响，用户命名空间兑现了安全地允许非特权用户访问以前仅限于根用户的功能的承诺。这反过来又为新型用户空间应用程序创造了有趣的可能性。例如，现在非特权用户可以在没有root权限的情况下运行Linux容器，构建Chrome 风格的沙箱无需使用 set-user-ID-root 帮助程序来实现假根类型应用程序不使用动态链接技巧，并实现
chroot()基于应用程序用于进程隔离。排除内核错误，使用用户命名空间访问特权内核功能的应用程序比基于 set-user-ID-root 的传统应用程序更安全：使用基于用户命名空间的方法，即使应用程序受到损害，它也不会受到影响。任何可用于对更广泛的系统造成损害的特权。
也就是说，添加对用户命名空间的支持本身就给 Linux 带来了许多安全漏洞（仅举一个例子），直到某些分布默认情况下禁用用户命名空间的非特权创建。
如果您正在寻找资源，关于命名空间的 LWN 系列的其余部分更深入地涵盖了该主题。