☰

关于在新创建的挂载命名空间内挂载和卸载继承的挂载

tag-icon • tag-icon mount linux-kernel namespace
关于在新创建的挂载命名空间内挂载和卸载继承的挂载

实验1

从命名空间外部，cat /proc/self/mountinfo给出

291 34 0:37 / /tmp/IMJUSTTMP rw,relatime shared:152 - tmpfs tmpfs rw,size=102400k
34 23 0:32 / /tmp rw,nosuid,nodev shared:16 - tmpfs tmpfs rw

然后我运行unshare -mU --map-root-user --propagation private /usr/bin/zsh在命名空间内获取一个新的 shell，但在新创建的安装命名空间内，我无法 umount /tmp/IMJUSTTMP，umount只是告诉我它尚未安装。虽然我可以通过 检查新创建的挂载命名空间cat /proc/self/mountinfo，它提供了私有挂载

290 263 0:32 / /tmp rw,nosuid,nodev - tmpfs tmpfs rw
302 290 0:37 / /tmp/IMJUSTTMP rw,relatime - tmpfs tmpfs rw,size=102400k

umount: /tmp/IMJUSTTMP: not mounted.那么为什么当我尝试/tmp/IMJUSTTMP在命名空间内卸载时会出现这种情况呢？

我正在使用 5.0.9-arch1-1-ARCH，带有kernel.unprivileged_userns_clone = 1.

实验2

之后unshare -mU --map-root-user --propagation private /usr/bin/zsh，尝试创建一个overlayfs也失败。

mkdir -p /tmp/IMJUSTTMP/work
mkdir /tmp/IMJUSTTEST
mount -t tmpfs -o size=100m tmpfs /tmp/IMJUSTTMP
mount -t tmpfs -o size=200M tmpfs /tmp/IMJUSTTEST

一切都会按预期成功，而以下所有内容都会进入permission denied命名空间。

mount -t overlay -o "lowerdir=/home/xtricman,upperdir=/tmp/IMJUSTTMP/,workdir=/tmp/IMJUSTTMP/work" overlay /home/xtricman
mount -t overlay -o "lowerdir=/tmp/IMJUSTTEST,upperdir=/tmp/IMJUSTTMP,workdir=/tmp/IMJUSTTMP/work" overlay /mnt

我的粗略猜测

我发现这两个问题，在用户命名空间内，为什么不允许我重新挂载已挂载的文件系统？和为什么我不能在用户命名空间内绑定挂载“/”？看来，由于我继承了/tmp/IMJUSTTMP和/tmpmount，所以即使我在新创建的挂载命名空间的所属用户命名空间中获得了完整的功能，我也无法卸载它们。

问题

谁能解释一下这两个实验究竟发生了什么？是否有任何文档提到在挂载命名空间内挂载和卸载的详细内核行为？什么是“超级区块所有者”这个内核提交和为什么我不能在用户命名空间内绑定挂载“/”？？

答案1

是的 ：-）。这里有三个不同的点。

umount: /tmp/IMJUSTTMP: not mounted实验 1：为什么当我尝试umount /tmp/IMJUSTTMP进入命名空间时出现错误？

挂载命名空间(7)

[...]

挂载命名空间的限制

关于挂载命名空间，请注意以下几点：

  1. 每个挂载命名空间都有一个所有者用户命名空间。如上所述，当创建新的挂载命名空间时，其挂载列表被初始化为另一个挂载命名空间的挂载列表的副本。如果新的命名空间和复制挂载列表的命名空间属于不同的用户命名空间，则新的挂载命名空间被视为权限较低。

  2. 创建特权较低的挂载命名空间时，共享挂载将减少为从属挂载。这可确保在特权较低的安装命名空间中执行的映射不会传播到特权较高的安装命名空间。

  3. 来自特权较高的挂载命名空间的作为单个单元的挂载被锁定在一起，并且不能在特权较低的挂载命名空间中分开。 （unshare(2) CLONE_NEWNS 操作将原始挂载命名空间中的所有挂载作为单个单元进行传输，并且在挂载命名空间之间传播的递归挂载作为单个单元进行传播。）

[...]

实验2：尝试创建overlayfs也失败

非特权文件系统挂载，2018 版 [LWN.net]

尝试让挂载操作对于普通用户来说是安全的，这并不是什么新鲜事。低水温网络覆盖一套补丁早在 2008 年。这项工作从未被合并，但允许非特权挂载的努力已接2015 年，Eric Biederman（以及其他人，特别是 Seth Forshee）开始认真考虑允许用户命名空间执行文件系统挂载。这初步工作 于 2016 年合并到 4.8 内核，但已知它并不是问题的完整解决方案，因此大多数文件系统仍然只能由在初始命名空间中具有特权的用户挂载。

2008 年 LWN 文章称，已被验证为“可在用户命名空间内安全使用”的文件系统被标记为FS_USERNS_MOUNT.这样我们就可以很容易的搜索到允许哪些文件系统。

注意这个标志已添加到内核版本5.11的OverlayFS中。因此，您现在可以在特权用户和挂载命名空间内挂载一个。

此内核提交中提到的“超级块所有者”是什么以及问题“为什么我不能在用户命名空间内绑定挂载“/”？” ？

您链接到的内核提交中的源代码表示每个超级块都被视为由特定用户命名空间拥有。所有者是最初创建超级块的用户命名空间。

相关内容