主页 / unix / 问题 / 517317
Accepted
炸鱼薯条德里克
Asked: 2019-05-06 18:37:17 +0800 CST

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

  • 772

实验一

从命名空间之外，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在命名空间内获取一个新外壳，但在新创建的挂载命名空间内，我不能 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.

实验二

之后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和/tmp挂载，所以即使我在新创建的挂载命名空间的拥有用户命名空间中获得了全部功能，我也无法卸载它们。

问题

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

linux-kernel mount

1 个回答

  1. Best Answer

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

    实验一：为什么umount: /tmp/IMJUSTTMP: not mounted我尝试umount /tmp/IMJUSTTMP进入命名空间时会得到？

    http://man7.org/linux/man-pages/man7/mount_namespaces.7.html

    挂载命名空间的限制

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

    • 挂载命名空间具有所有者用户命名空间。所有者用户命名空间与其父挂载命名空间的所有者用户命名空间不同的挂载命名空间被视为特权较低的挂载命名空间。

    • 在创建特权较低的挂载命名空间时，共享挂载会减少为从属挂载。（共享挂载和从属挂载将在下面讨论。）这确保了在特权较低的挂载命名空间中执行的映射不会传播到特权更高的挂载命名空间。

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

    • mount(2) 标志 MS_RDONLY、MS_NOSUID、MS_NOEXEC 和“atime”标志（MS_NOATIME、MS_NODIRATIME、MS_RELATIME）设置在从特权更高的挂载命名空间传播到特权较低的挂载命名空间时会被锁定，并且不能在较少特权的挂载命名空间。

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

    尝试使普通用户的挂载操作安全并不是什么新鲜事。LWN涵盖了 2008 年的一个补丁集。这项工作从未合并，但在 2015 年，当 Eric Biederman（以及其他人，特别是 Seth Forshee）认真考虑允许用户命名空间执行文件系统挂载时，允许非特权挂载的努力得到了加强. 最初的工作 是在 2016 年为 4.8 内核合并的，但众所周知这不是解决问题的完整方案，因此大多数文件系统仍然只能由在初始命名空间中具有特权的用户挂载。

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

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

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

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

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

    • 2

相关问题