Linux mount namespace 挂载事件为什么串到宿主机：shared、slave、private 的验证与隔离

在 Linux 上用 unshare -m 做临时挂载测试时，最容易碰到的反常情况是：明明已经做了命名空间隔离，新挂载还是会出现在另一个运行环境里。这基本不是 mount namespace 本身失效，而是对应挂载点仍处于 shared propagation 共享组中，mount 和 umount 事件会沿着预设的共享关系跨命名空间传播。

命名空间明明做了隔离，挂载为什么还能“跨环境串门”

mount namespace 隔离的只是进程能看到的挂载树视图，Linux 额外提供了 shared subtrees 机制，允许指定的一批挂载点之间自动同步 mount 与 umount 事件。现在主流发行版默认会通过 systemd 把部分系统挂载点设为 shared 模式，所以只执行 unshare -m 操作，并不等于新生成的子挂载自动就是 private 模式。

排查这类问题先看挂载传播属性，不要上来就改内核参数：

findmnt -o TARGET,FSTYPE,PROPAGATION
findmnt -T /tmp -o TARGET,PROPAGATION
grep -E ' /tmp | /run ' /proc/self/mountinfo

在 /proc/self/mountinfo 的输出里，shared:X 标记代表该挂载属于共享同步组，master:X 标记代表它会从指定共享组接收事件；这些标记比只看目录路径的判断靠谱得多。

三种传播属性分别对应什么场景

shared：多方都要同步挂载变化

shared 模式下新建或卸载的子挂载，会自动同步给同一 peer group 里的所有其他成员。它适合宿主机和多个运行环境需要同步设备或文件系统视图的场景，但完全不适合随手做隔离测试：在 namespace 内部创建的测试挂载，会直接同步到宿主机对应的共享挂载点。

mount --make-shared /mnt/lab
findmnt -T /mnt/lab -o TARGET,PROPAGATION

slave：只允许上游的挂载事件单向流入

slave 模式会接收 master 侧的挂载和卸载事件，但本地新增的挂载事件不会反向传播回 master。容器运行时经常用到这种单向关系：宿主机的新挂载能自动同步进容器视图，容器内部的临时挂载不会反过来污染宿主机的挂载树。

mount --make-rslave /mnt/lab
findmnt -T /mnt/lab -o TARGET,PROPAGATION

--make-rslave 操作会递归处理整个子树，在生产环境执行前一定要确认目标路径和当前进程权限符合预期。

private：两边完全不交换挂载事件

private 模式的挂载不会向外发送自己的变更，也不会从外部接收任何传播事件。对于一次性的 mount namespace 隔离实验来说，它是逻辑最简单、最不容易出意外的默认起始配置：

mount --make-rprivate /mnt/lab
findmnt -T /mnt/lab -o TARGET,PROPAGATION

这里要注意核心控制项是挂载点的传播属性，不是文件夹权限。哪怕文件夹的可写权限已经放开，传播属性依然能决定一个 mount 操作会不会被其他 namespace 里的进程看到。

用最简实验验证传播方向

这类验证操作最好放在可随时销毁的虚拟机或测试节点上，绝对不要直接对生产环境的根挂载执行递归属性变更。先创建独立的测试文件夹和隔离 namespace：

mkdir -p /tmp/ns-lab/source /tmp/ns-lab/inside
unshare --mount --fork sh -c 'findmnt -T /tmp/ns-lab -o TARGET,PROPAGATION; mount -t tmpfs tmpfs /tmp/ns-lab/inside; findmnt -T /tmp/ns-lab/inside'

如果外层的 findmnt 也能看到 /tmp/ns-lab/inside，先分别记录外层和内层挂载点的传播属性，再往上检查父挂载是否为 shared 模式。不要把单次观察结果直接归因于 namespace 类型，父挂载的传播关系才是决定事件流向的核心因素。

验证完成后，直接退出测试用的隔离 shell 清理临时挂载，再次确认 findmnt -R /tmp/ns-lab 没有残留挂载。生产环境更推荐用 systemd、容器运行时或编排平台统一管理挂载生命周期，避免手工执行的命令和平台默认编排规则互相覆盖。

兼容处理与安全边界

如果程序需要自动接收宿主机的新挂载，但不允许把自身内部的挂载传回宿主机，优先选用 slave 模式；如果目标只是做隔离性临时测试，优先选 private 模式；只有确认两端必须自动同步挂载视图的场景，才考虑使用 shared 模式。

• 调整挂载传播属性前先保存 findmnt -R 和 /proc/self/mountinfo 的查询结果，方便后续回滚和问题复盘。
• 递归属性变更会覆盖整个子树下的所有挂载点，目标路径必须使用绝对路径，并且提前在测试节点完成操作验证。
• 挂载传播规则不能替代文件权限、用户命名空间或 SELinux/AppArmor 等其他安全管控手段。

常见问题

mount namespace 生成后默认就是 private 模式吗？

不是。新生成的 namespace 会直接复制父进程的全部挂载列表，继承原有挂载的所有传播属性，后续的 mount/umount 事件依然会受原有传播规则影响；需要用 findmnt 或直接读取 mountinfo 确认实际属性。

slave 模式会把容器内部的挂载传回宿主机吗？

不会。slave 只接收上游 master 的传播事件，不会向 master 反向发送本地生成的挂载事件。

为什么我执行 unshare 之后得到的结果和网上教程不一样？

常见原因是当前发行版启动时已经把父挂载默认设为 shared 模式，或者你用的实验文件夹本身位于一个已经配置了传播关系的子树中。操作前先把父级和目标级的挂载传播标记都记录下来再对比排查。

把挂载改成 private 模式之后还能恢复事件同步吗？

确认影响范围后可以重新设置回 shared 或 slave 模式，但恢复同步之前要先清理掉不想对外传播的子挂载，再重新检查所属的 peer group 配置。

固定排查处理流程

碰到“namespace 里的挂载跑到外部环境”这类问题时，按「查询传播属性→确认父挂载配置→判断事件流向→选定 private/slave/shared 模式→复测完成后清理现场」的顺序处理。这套流程能把命名空间隔离、权限控制、挂载传播三个容易混淆的层级拆开处理，也没必要为了单个测试挂载的异常去改动整台机器的系统配置。