Linux namespace 隔离后为什么进程仍能看到部分宿主信息

容器里执行 ps、查看 /proc 或检查挂载时，看到几行宿主信息并不一定说明 namespace 失效。Linux namespace 隔离的是某一类全局资源的视图，不是把宿主机复制成一台完整虚拟机；mount、PID、network 三种 namespace 也互相独立。排查时要先确认进程加入了哪些 namespace，再检查它看到的 /proc 是否匹配，最后看挂载传播属性。

最常见的原因是“只隔离了一部分”：PID namespace 只改变进程编号视图，mount namespace 默认从原挂载列表复制一份，shared mount 还可能传播挂载事件。先看 /proc//ns/* 的标识，再看 mountinfo，不要直接把“能看到宿主信息”归因于权限问题。

先区分三种命名空间各自隔离什么

Linux 手册把 namespace 描述为对全局资源的抽象视图。它只包住指定资源，进程在视图内看到的是“自己的一份”，其他资源仍可能来自宿主。本文只看三类边界：

因此，“容器内能看到宿主内核版本”与“容器内能列出宿主进程”不是同一件事。前者本来就可能成立；后者通常要继续检查 PID 视图和 /proc 的挂载来源。

用 /proc/pid/ns 判断进程到底加入了哪些视图

不要只看进程名或容器标签。对目标进程与当前 shell 分别读取 namespace 符号链接，方括号里的 inode 标识相同，才说明它们处于同一个对应 namespace。下面的检查不修改系统状态：

pid=1234
# 逐项比较目标进程与当前 shell 的 namespace 标识
for ns in mnt pid net; do
  printf '%s: target=' "$ns"
  readlink "/proc/$pid/ns/$ns"
  printf '%s: self=' "$ns"
  readlink "/proc/self/ns/$ns"
done

例如 mnt:[402653xxxx] 不同，说明目录视图可能已经隔离；pid 相同，则进程编号仍共享当前 PID 视图。PID namespace 具有层级关系，外层进程可以观察到内层进程，但内层不必然拥有反向视图。这个结果只回答“加入了哪个视图”，还不能回答 /proc 是否挂到了正确的 PID namespace。

检查 /proc 挂载和 mount propagation

很多排查停在 unshare -m 或容器参数上，遗漏了两个细节。第一，新的 mount namespace 初始会复制创建者的挂载列表；它不是天然空目录。第二，挂载点的传播类型可以让 mount 或 umount 事件在 namespace 之间自动传播。

pid=1234
# 查看目标进程的 proc 挂载记录，确认它绑定的 PID 视图
grep ' /proc ' "/proc/$pid/mountinfo"
# 查看当前视图中的传播标签：shared、master 或无标签(private)
grep -E '(^| )(shared|master|propagate_from):' "/proc/$pid/mountinfo"
# 对比三类 namespace 的句柄，避免只凭目录内容下结论
ls -l "/proc/$pid/ns/mnt" "/proc/$pid/ns/pid" "/proc/$pid/ns/net"

mountinfo 出现 shared:N，表示该挂载在共享 peer group 中，下面的挂载事件可能传播到其他 peer；master:N 表示它是 slave，只接收来自 master 的传播。没有这些可选标签时通常是 private。生产环境需要的是边界判断：如果只想让新 mount namespace 不把变化带回宿主，先评估是否可将目标挂载设为 private 或 slave，而不是盲目重建容器。

按证据选择处理、回滚和复查

现场处理可以按下面的顺序收敛范围：

1. 先保存证据。记录目标 PID、三个 namespace 链接和目标 mountinfo，避免重启后失去现场。
2. 只修对应边界。目录可见异常优先看 mount 与 /proc；进程列表异常优先看 PID namespace 和 proc 挂载；端口冲突再看 network namespace。
3. 变更前保留回退。记录原传播属性与启动参数；若业务依赖宿主传播，先在一台非关键实例灰度，失败时恢复原参数。
4. 用同一组证据复查。重新读取 namespace inode、/proc 挂载行和 propagation 标签，确认视图变化而不是只看到命令成功返回。

需要进入目标进程的 namespace 做人工核对时，可使用 nsenter，但它本身不是隔离修复工具；它只是让检查者进入指定视图。权限不足、进程已退出或目标 namespace 没有对应句柄时，应保留原错误并回到宿主侧检查，而不是反复执行同一个命令。

常见问题

为什么 namespace 隔离后还能看到宿主内核版本？

因为 namespace 主要隔离资源视图，内核本身仍由宿主提供；这不能单独证明 mount 或 PID 隔离失败。

mount namespace 创建后为什么目录还是很多？

新 mount namespace 默认从原 namespace 复制挂载列表，后续变更才在默认情况下彼此独立；还要检查 shared propagation。

PID namespace 隔离后为什么还能看到一个外层 PID？

PID namespace 是层级结构，外层可以观察内层；请比较目标进程的 /proc//ns/pid 和 proc 挂载对象。

network namespace 与目录可见性有关吗？

没有直接关系。network namespace 负责网络设备、协议栈和端口，目录与进程列表应分别检查 mount、PID 和 /proc。