如何获取父挂载命名空间的文件描述符？

Question

在此页面中：https://man7.org/linux/man-pages/man2/ioctl_ns.2.html

它提到了如何获取引用

fd

所引用的命名空间的父命名空间的文件描述符。它提到它仅适用于分层命名空间，即用户命名空间和 pid 命名空间。

但是，阅读挂载命名空间的手册页（https://man7.org/linux/man-pages/man7/mount_namespaces.7.html），其中提到挂载命名空间也具有父子关系。这种父子关系对于共享子树之类的东西很重要。

所以我的问题是，mount命名空间不也是一个分层命名空间吗？我认为答案应该是肯定的，如果是这样，我如何获得父挂载命名空间的

fd

，类似于上面共享的第一个链接中代码提供父pid/用户命名空间的

fd

？

Answer 1

简而言之，挂载命名空间不是分层的，因此父命名空间 ioctl

NS_GET_PARENT

在提供引用挂载命名空间的文件描述符时会返回错误。但是挂载点是有层次的，但我们会谈到这一点。

不幸的是，您没有给出为什么您认为挂载命名空间应该是分层的。但是让我们看一下 Michael 的手册页 在 mount_namespaces(7) 上。描述部分的第二段说：

挂载命名空间提供了对挂载列表的隔离 每个命名空间实例中的进程。

这与namespaces(7)中的描述一致。

现在，关于“共享子树”的部分解释：

[...] Linux 中引入了共享子树功能 2.6.15. 此功能允许自动、受控 mount(2) 和 umount(2) 事件在命名空间之间的传播 （或者，更准确地说，在属于某个成员的坐骑之间 相互传播事件的同侪群体）。

挂载和卸载事件因此与挂载点相关。这些事件的传播方式由父挂载点控制。此信息由内核通过

/proc/$PID/mountinfo

伪文件公开。为了获得完整的情况，您需要首先找到所有挂载命名空间，然后在每个挂载命名空间中解析一次所有挂载信息文件。

mountinfo 中的信息非常复杂，因为虽然有一个 mount path 层次结构，但还有一个完全独立的 mount point 层次结构。挂载点层次结构可以包含过度挂载，无论是就地挂载还是 VFS 路径中较高的挂载点都可能完全隐藏较早的挂载点及其挂载路径。

我前段时间为此编写了一个发现工具，处理来自不同挂载命名空间的mountinfo数据的部分可以在这里看到：https://github.com/thediveo/lxkns/blob/master/mounts/mount。去。这会计算挂载路径树，正确处理每个挂载点层次结构的过载。

您可以通过我的 lxkns 命名空间和挂载点发现工具的 Web UI 轻松使用它。您可以使用单个命令将该工具部署到 Docker，请参阅 lxkns 的主页。在 UI 中，打开汉堡菜单，选择挂载命名空间，然后浏览挂载树。 UI 还向您显示子树传播；单击“...”按钮查看详细信息。