CLONE_NEWNS 和挂载传播答案

【问题标题】：CLONE_NEWNS and mount propagateCLONE_NEWNS 和挂载传播
【发布时间】：2013-03-28 04:38:16
【问题描述】：

我目前正在寻找一些例子来理解 linux 中的 CLONE_NEWNS，所以我做了以下实验：

在 shell1 中：

$ mkdir mnt
$ sudo unshare -m /bin/bash
# mount /dev/sda5 mnt/
# ls mnt
lost+found

如在 shell2 中：

$ ls mnt
lost+found

我希望 shell2 中的输出应该是空的，因为 CLONE_NEWNS 将创建一个新的挂载命名空间，如文档所述。

首先，我认为孩子的命名空间挂载会传播到父母的，所以我在父母身上挂载，孩子也看到挂载！

然后，我从同一个父级创建两个独立的子命名空间，挂载在一个子级中也会影响另一个。

我很困惑。

ps。在我的第一个实验中在 shell1 中：

# readlink /proc/$$/ns/mnt
mnt:[4026532353]

在 shell2 中：

$ readlink /proc/$$/ns/mnt
mnt:[4026531840]

显然，它们位于不同的挂载命名空间中。

【问题讨论】：

标签： linux filesystems kernel linux-namespaces

【解决方案1】：

不同的挂载命名空间只是意味着子命名空间中的 [u]mount-actions 在父命名空间中不可见。这并不意味着，父项中的挂载在子项中不可见，也不意味着所有挂载都消失了。

要尝试一下，您可以 [un] 在子命名空间中挂载一些东西，看看它是否 [仍然] 存在于父命名空间中。

【讨论】：

【解决方案2】：

Linux 似乎完全落后了，我不完全确定为什么。

但是如果你在 shell2 中mount /dev/sda5 mnt/，那么在 shell1 中的ls mnt 应该不会显示 LOST+FOUND。 shell1 中的子命名空间有效地保护它免受其父命名空间的任何更改，但父命名空间由子命名空间更改。有点像反向沙盒，其中父命名空间是可以由子命名空间更改的命名空间，反之则不行。

我不知道为什么会这样，并且可能存在不同的情况，但我不知道它们。我对此可能大错特错，但我测试了上述操作，它似乎确实阻止了 mnt/ 被安装在 shell2 中。

解决您的问题的一个可能方法是使用 unshare 创建一种特权挂载命名空间，您可以在其中执行所有根操作，并且它是您用于正常非特权帐户和操作的父命名空间。所以，就像...

[shell1] # unshare -m bash
[shell2] # sudo -u normal-user startx
[shell1] # mount /dev/privatesecret /mnt/secretplace

...类似的东西。显然，如果有人获得 root 权限，他们可以 ptrace 您的进程，但子命名空间将使 [shell1] 中的私有挂载对 [shell2] 或其他任何地方的任何操作完全隐藏，前提是您在执行任何操作之前降低到正常用户权限可能会弄乱它。

我很确定，反向沙盒仅适用于挂载命名空间。 PID 命名空间将被适当地沙盒化，这样子级就不会看到父级的 PID，并且内存命名空间的子级在内存中的限制比父级更大。

【讨论】：