挂载命名空间 API 是否可以有效地变得多余？会有什么障碍？

Question

1. 您仍然可以访问不同安装命名空间中的文件和目录，如果你有他们的参考。但是，当前您无法操作（甚至列出）挂载命名空间的挂载，如果它不是您正在运行的命名空间。
2. 分离挂载 ( umount -l) 被视为没有挂载命名空间，因此不允许您操作它们（或列出子挂载）。

第 1 点（或第 2 点）中的限制对于命名空间 API 是否至关重要，例如出于安全考虑？现有软件是否依赖它？

如果不是，那么从 Linux 代码中消除第 2 点（和第 1 点）的限制是否会很困难？也就是说，这样做的主要障碍是什么？

动机：如果您可以创建分离的挂载树，您就可以chroot进入它们，并且我认为挂载命名空间基本上是多余的。尽管它们仍然会为其他类型的 Linux 命名空间提供一些便利/一致性。

Answer 1

如果你可以构建一个分离的挂载树，你就可以chroot进入它，我认为挂载命名空间基本上是多余的。尽管它们仍然会为其他类型的 Linux 命名空间提供一些便利/一致性。

我认为（至少）我错过了重要的一点。

命名空间的特征之一是它们与用户命名空间相关联。用户命名空间隔离“超级用户”功能，例如 CAP_SYS_ADMIN 和 CAP_NET_RAW。例如，CAP_NET_RAW 可以允许访问网络设备上的原始网络数据包 - 如果它们由属于您的用户的网络命名空间拥有。

CAP_SYS_ADMIN 允许您操作属于您的用户的挂载命名空间。当前的限制可能比严格需要的更严格，但您需要一些限制。将挂载树绑定到命名空间是必要的，以便用户命名空间可以隔离 CAP_MOUNT。

我想实现一些挂载命名空间的替代方案没有多大意义，因为它不适用于用户命名空间。