命名空间——用户ID（user）

命名空间——用户ID（user）

用户命名空间（User Namespace）是 Linux 中隔离用户 ID（UID）和组 ID（GID）权限的机制，它的核心价值是：让进程在命名空间“内部”拥有的权限（比如 root）与在命名空间“外部”（主机）的实际权限完全分离。这为“无根容器”（不需要主机 root 权限就能运行的容器）提供了底层支持，极大提升了容器的安全性。

一、用户命名空间的核心：“内外身份两张皮”

在没有用户命名空间时，进程的 UID/GID 是全局有效的——比如主机上的 UID=0（root）在整个系统中都拥有最高权限。

用户命名空间打破了这种全局唯一性，实现了“身份映射”：

• 一个进程可以在命名空间内部是 UID=0（看起来是 root，拥有命名空间内的所有权限）；
• 但在命名空间外部（主机系统），它可能只是一个普通用户（比如 UID=1000，没有主机的 root 权限）。

这种“内外身份分离”的特性，解决了一个关键问题：既让容器内的进程获得必要的 root 权限（比如绑定 80 端口、修改系统配置），又不让它真正拥有主机的 root 权限，避免安全风险。

二、关键机制：UID/GID 映射（uid_map 和 gid_map）

用户命名空间通过“映射文件”记录内外 UID/GID 的对应关系，这些文件位于 /proc/[进程PID]/uid_map（用户ID映射）和 /proc/[进程PID]/gid_map（组ID映射）。

映射文件的格式

每个映射文件的内容是一行或多行，格式为：

内部ID  外部ID  长度

• 内部ID：命名空间内进程看到的 UID/GID（比如容器内的 UID=0）；
• 外部ID：主机系统中实际的 UID/GID（比如主机的 UID=1000）；
• 长度：连续映射的ID数量（比如长度=1表示只映射这一个ID，长度=10表示从内部ID开始连续10个ID都映射到外部ID开始的10个ID）。

举例说明

假设某进程在用户命名空间内的 uid_map 内容为：

0  1000  1

含义是：

• 命名空间内的 UID=0（root），映射到主机的 UID=1000（普通用户）；
• 长度=1 表示只映射这一个ID（即只有内部 UID=0 对应外部 UID=1000）。

此时，该进程在命名空间内执行 id -u 会显示 0（看起来是 root），但在主机上用 ps -ef 查看，它的真实 UID 是 1000。

三、权限检查：映射如何影响实际操作？

当命名空间内的进程操作文件或资源时，内核会自动进行“映射转换”来检查权限：

1. 进程访问文件时：
   内核会把进程的“内部 UID/GID”转换为“外部 UID/GID”（通过 uid_map/gid_map），然后用外部 ID 检查权限。
   例如：内部 UID=0 映射到外部 UID=1000，当进程尝试修改一个只有 UID=1000 有权限的文件时，会被允许（因为实际用外部 ID 检查）；但如果尝试修改主机上只有 root 能改的文件（比如 /etc/passwd），会被拒绝（因为外部 ID 是 1000，没有权限）。

2. 进程查询文件属性时：
   当进程通过 stat() 等系统调用获取文件的 UID/GID 时，内核会做“反向映射”——把文件的外部 ID 转换为内部 ID 后返回。
   例如：主机上属于 UID=1000 的文件，在命名空间内会被显示为 UID=0（让内部进程觉得这是“自己的文件”）。

四、未映射的 ID：溢出用户（overflow UID）

如果进程在命名空间内的 UID/GID 没有在 uid_map/gid_map 中定义（即“未映射”），内核会自动将其转换为“溢出 ID”：

• 溢出 UID 默认为 65534（对应用户名 nobody）；
• 溢出 GID 默认为 65534（对应组名 nogroup）。

这通常发生在“刚创建用户命名空间但还没设置映射”的场景。例如：

# 在主机上查看当前用户 UID（假设是 1000）
id -u  # 输出：1000

# 创建新的用户命名空间并进入（未设置映射）
unshare -U /bin/bash

# 在命名空间内查看 UID（未映射，显示溢出 ID）
id -u  # 输出：65534（nobody）

五、安全控制：setgroups 文件

/proc/[进程PID]/setgroups 文件用于控制命名空间内是否允许调用 setgroups() 系统调用（该调用用于修改进程的附加组列表）。文件内容只有两种：

• deny（默认）：禁止在命名空间内使用 setgroups()，防止非特权用户通过修改组权限越权；
• allow：允许使用 setgroups()（需要特殊权限）。

这个限制是为了解决用户命名空间的潜在安全问题：如果允许非特权用户随意修改组列表，可能会绕过主机的权限检查。

六、为什么用户命名空间对容器至关重要？

用户命名空间是“无根容器”（rootless container）的核心技术。传统容器需要主机 root 权限才能创建（因为要操作其他命名空间、挂载文件系统等），而用户命名空间让普通用户可以：

1. 创建一个用户命名空间，在其中自己是 UID=0（root）；
2. 结合其他命名空间（PID、mount 等），构建一个“看起来有完整 root 权限”的容器环境；
3. 但容器内的 root 操作会被映射到主机的普通用户权限，即使容器被攻破，也无法获取主机的 root 权限。

这极大降低了容器的安全风险，现在主流容器工具（如 Docker、Podman）都支持基于用户命名空间的无根模式。

总结

用户命名空间的核心是“UID/GID 映射”，实现了进程“内外权限分离”：

• 内部可以是 root，拥有隔离环境内的完整权限；
• 外部映射为普通用户，受限于主机的权限控制；
• 这为容器提供了安全的隔离基础，尤其是无根容器的普及。

简单说，用户命名空间让进程“在自己的小世界里当管理员，在主机的大世界里做普通人”。