在阅读了 Linux 命名空间之后，我的印象是，在许多其他功能中，它们是 chroot 的替代品。例如，在这篇文章中：
[名称空间] 的其他用途包括 [...] chroot() 式将进程隔离到单个目录层次结构的一部分。
但是，当我克隆 mount 命名空间时，例如使用以下命令，我仍然看到整个原始根树。
unshare --mount -- /bin/bash
我知道我现在能够在不与原始命名空间共享的新命名空间中执行额外的挂载，因此这提供了隔离，但它仍然是同一个根，例如/etc两个命名空间仍然相同。我还需要chroot更改根目录还是有其他选择？
我期待这个问题会提供答案，但答案chroot再次仅使用, 。
有一条现已删除的评论提到pivot_root。由于这实际上是 的一部分linux/fs/namespace.c，因此它实际上是名称空间实现的一部分。这表明仅使用unshare和更改根目录mount是不可能的，但命名空间提供了一个自己的——更聪明的—— chroot. chroot即使在阅读源代码之后（例如在安全性或更好的隔离的意义上），我仍然不明白这种方法的主要思想，这使得它与 根本不同。
这不是这个问题的重复。执行完答案中的所有命令后，我有单独的 /tmp/tmp.vyM9IwnKuY（或类似的），但根目录仍然相同！
我观察到以下我无法解释的现象。添加CAP_SYS_ADMIN功能后，unshare不再能够写入/proc/self/setgroups.
实际上，写入此文件需要该功能，但这是通过更改用户命名空间来实现的。那么为什么向父进程添加功能会阻止写入此文件呢？
me@myhost:~$ unshare -r
root@myhost:~# exit
logout
me@myhost:~$ sudo setcap cap_sys_admin=ep /usr/bin/unshare
me@myhost:~$ unshare -r
unshare: cannot open /proc/self/setgroups: Permission denied
me@myhost:~$ sudo setcap cap_sys_admin= /usr/bin/unshare
me@myhost:~$ unshare -r
root@myhost:~#
顺便说一句：我正在运行内核版本为 4.4 的 Ubuntu 16.04.4 LTS，并且 util-linux（包括unshare）的版本为 2.27.1。