Mount Namespace 提供文件系统视图隔离，但需与 rootfs 协同并执行 pivot_root、重挂载伪文件系统及设 MS_PRIVATE 才能实现真正的根目录独立与安全。
挂载命名空间（Mount Namespace）本身不直接“确保安全性”，而是提供文件系统视图的隔离基础。真正的根路径独立性和安全性，依赖于 Mount Namespace 与 rootfs 的协同使用，再配合正确的挂载操作和权限控制。
rootfs 是容器根路径的物理来源
容器启动前必须准备一套完整的目录树（即 rootfs），例如：
• /bin、/lib、/etc、/usr 等基本目录
• 目标程序及其所有依赖库（可用 ldd 检查）
• 不包含宿主机敏感路径（如 /root、/home、/var/lib/docker）
这个目录树不是虚拟的，而是真实存在于宿主机某处（如 /var/lib/docker/overlay2/xxx/diff），但它仅作为容器进程的“起点”。没有 Mount Namespace，进程仍能看到宿主机全部挂载点；有了它，才能把这套目录真正变成容器眼中的 /。
Mount Namespace 提供视图隔离，但需主动挂载才生效
新建 Mount Namespace 时，内核会复制父命名空间的挂载点列表——这意味着刚创建的容器进程默认看到的仍是宿主机的 / 和所有挂载项（如 /proc、/sys、/dev）。要让 rootfs 成为真正根目录，必须显式执行以下关键操作：
- 用 mount --bind 或 mount --rbind 将 rootfs 目录挂载到新命名空间的 /
- 立即执行 chroot 或更安全的 pivot_root 切换根目录（Docker 使用 pivot_root）
- 对关键伪文件系统（如 /proc、/sys、/dev）重新挂载，确保它们是容器专属的、空的或受限版本
- 将根挂载设为私有（MS_PRIVATE），防止宿主机挂载传播影响容器（尤其当宿主机根为 shared 时）
避免常见陷阱：隔离≠自动安全
仅启用 Mount Namespace 不等于根路径已独立。典型风险包括：
- 未重挂载 /tmp 或 /dev/shm：可能继承宿主机可写 tmpfs，造成信息泄露或拒绝服务
- 未屏蔽 /proc/sys、/sys/fs/cgroup：容器可能读取或误改宿主机内核参数
- 未清理父命名空间挂载点：如忘记 umount /mnt、/media 等，容器内仍可见宿主机挂载设备
- 使用 bind mount 时未加 noexec,nosuid,nodev：可能绕过执行限制
建议在挂载 rootfs 后，用 findmnt -n -o SOURCE,TARGET,FSTYPE / 验证当前根是否指向预期目录，并检查 /proc/self/mountinfo 确认无意外挂载项。
结合其他机制加固边界
Mount Namespace 是基础，但完整安全性还需叠加：
- 用户命名空间（UserNS）：让容器内 root 映射为宿主机非特权用户，防止挂载逃逸后提权
- 只读挂载（ro）：对 /usr、/bin 等系统目录设为只读，防篡改
- tmpfs 覆盖敏感路径：如 mount -t tmpfs none /run、/tmp，避免残留数据
- seccomp/bpf 过滤 mount 系统调用：限制容器内进程自行挂载新文件系统
不复杂但容易忽略。核心就两点：先有干净 rootfs，再用 Mount Namespace 把它真正“立”为容器的 /，其余都是围绕这个动作做减法和加固。
