我目前正在寻找一些例子来了解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将创建一个新的mount命名空间，如文档所述。
首先，我认为孩子的名称空间挂载会传播给父母，所以我会挂载父母，孩子也看挂载！
然后，我从同一个父级创建两个单独的子命名空间，mount在一个子级中也会影响另一个。
我很困惑。
PS。在我的第一个实验中 在shell1中：
# readlink /proc/$$/ns/mnt
mnt:[4026532353]
：
$ readlink /proc/$$/ns/mnt
mnt:[4026531840]
显然，它们位于不同的mount命名空间中。
答案 0 :(得分：0)
不同的mount命名空间只是意味着，子命名空间中的[u] mount-actions在父级中不可见。具体而言，并不意味着，父母的坐骑在孩子身上不可见，也不意味着所有坐骑都消失了。
要尝试它，你可以在子命名空间中[un]挂载一些内容，看看它是否仍然存在于父命名空间中。
答案 1 :(得分：0)
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]或其他任何地方的任何操作中，前提是你在执行任何操作之前删除了普通用户权限可能会搞砸它。
反向沙盒的东西只适用于mount命名空间，我相当肯定。 PID命名空间将被正确地沙箱化，以便子节点看不到父节点的PID，并且内存命名空间的子节点内存比父节点更受限制。