koalo's questions

我观察到以下我无法解释的现象。添加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。

在阅读了 Linux 命名空间之后，我的印象是，在许多其他特性中，它们是 chroot 的替代品。例如，在这篇文章中：

[命名空间] 的其他用途包括 [...] chroot() 风格的进程隔离到单个目录层次结构的一部分。

但是，当我克隆挂载命名空间时，例如使用以下命令，我仍然可以看到整个原始根树。

unshare --mount -- /bin/bash

我知道我现在能够在不与原始命名空间共享的新命名空间中执行额外的挂载，因此这提供了隔离，但它仍然是同一个根，例如/etc对于两个命名空间来说仍然是相同的。我还需要chroot更改根目录还是有替代方法？

我原以为这个问题会提供答案，但答案仅使用chroot, 。

编辑#1

有一条现已删除的评论提到pivot_root. 由于这实际上是 的一部分linux/fs/namespace.c，因此它实际上是命名空间实现的一部分。这表明仅使用unshareand更改根目录mount是不可能的，但命名空间提供了一个自己的更聪明的chroot. chroot即使在阅读了源代码之后（例如在安全性或更好的隔离方面），我仍然不明白这种方法的主要思想，这使得它与.

编辑#2

这不是这个问题的重复。从答案中执行所有命令后，我有单独的 /tmp/tmp.vyM9IwnKuY （或类似的），但根目录仍然相同！