Linux user namespace怎样映射非root用户

如果你想让一个非 root 账号在 Linux user namespace 中看到自己的隔离身份，关键不是把宿主机账号“变成 root”，而是建立一张明确的 UID/GID 映射表：命名空间内的 UID 0 可以映射到宿主机启动者的普通 UID，映射范围由 uid_map 和 gid_map 三列决定。创建 user namespace 后，先写 UID 映射；需要写 GID 映射时，通常要先对 /proc//setgroups 写入 deny。

官方地址：https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html

最小可记忆规则是：uid_map 和 gid_map 都是一行或多行“三元组”，格式为“命名空间内起始 ID、父命名空间起始 ID、连续数量”；映射写入后不能随意改写，GID 映射前还要处理 setgroups 权限条件。

先把 user namespace 的身份边界分清

user namespace 只改变进程观察 UID、GID 和部分能力的方式。假设启动者在父命名空间中的 UID 是 1000，下面这组三元组：

# 第一列是子命名空间 UID，第二列是父命名空间 UID，第三列是连续数量
0 1000 1

表示：子 user namespace 内的 UID 0 对应父 user namespace 中的 UID 1000，连续映射 1 个 ID。于是子命名空间里的进程可能显示为 root，但它并没有因此获得宿主机 UID 0 的身份。

这里的“父命名空间”是映射文件写入者所处的 user namespace。不要只看数字本身：同一个进程在不同 user namespace 中读取身份信息，看到的数值可能不同。

三列映射到底表示什么

/proc//uid_map 每行有三个数字：

• 第一列：子 user namespace 中的起始 UID。
• 第二列：父 user namespace 中与它对应的起始 UID。
• 第三列：连续 ID 的数量。

例如 0 1000 1 只映射一个 UID；0 1000 100 则表示子命名空间的 0–99 映射到父命名空间的 1000–1099。未覆盖的 UID 不会自动“顺延”到宿主机用户。

创建一个等待映射的子 shell

实际编排时，父进程需要在子进程已经进入 user namespace、但还没有执行目标命令时写入映射。下面用 shell 展示结构，命令中的注释说明每个参数的作用；它是文章中的配置示例，不代表本文在本机执行过。

#!/usr/bin/env bash
set -eu

# 让 unshare 创建 user namespace，并在映射完成后执行 bash。
# --map-root-user 适合快速把当前普通用户映射为 namespace 内 UID 0。
unshare --user --map-root-user --fork --mount-proc bash -c '
  # 目标 shell 只在新的 user namespace 里观察身份。
  printf "namespace uid=%s gid=%s\\n" "$(id -u)" "$(id -g)"
' 

--map-root-user 是 util-linux unshare 提供的便捷选项。若你需要自定义多段 UID/GID 范围，就要改成“创建子进程、记录 PID、写入映射、解除等待、执行目标命令”的父子协作模型。

自定义 UID 映射时只写需要的范围

以启动者 UID 为 1000、只映射一个命名空间内 root 身份为例，核心写入形式如下：

# 假设 child_pid 已经是进入 user namespace 并正在等待的子进程 PID。
# 第一列 0 是子命名空间身份，第二列 1000 是父命名空间身份，第三列 1 是范围。
printf '%s\\n' '0 1000 1' > "/proc/${child_pid}/uid_map"

# 让子命名空间中的 GID 0 对应父命名空间中的 GID 1000。
printf '%s\\n' '0 1000 1' > "/proc/${child_pid}/gid_map"

映射文件的写入有严格条件：创建后初始为空，完成设置后不能当成普通配置文件反复覆盖；每一行的范围不能与同一文件的其他行重叠。若只需要一个普通账号的隔离身份，就不要为了“看起来完整”而映射整段宿主机 UID。

为什么 gid_map 前要处理 setgroups

GID 映射比 UID 映射多一个常见门槛：在父命名空间缺少相应能力时，写入 /proc//gid_map 前，父进程通常先向子进程的 setgroups 文件写入 deny。这会永久禁止该 user namespace 使用 setgroups(2)，随后才允许在较少权限条件下写 GID 映射。

# 先关闭子 user namespace 的 setgroups 能力，避免 gid_map 被权限条件拒绝。
printf '%s\\n' deny > "/proc/${child_pid}/setgroups"

# 再写入 GID 映射；第二列应使用父命名空间中允许映射的 GID。
printf '%s\\n' '0 1000 1' > "/proc/${child_pid}/gid_map"

这不是把 setgroups 当作普通开关来回切换：deny 写入后不能恢复为 allow。因此，只有当目标程序确实需要组身份切换时，才应在设计阶段评估父命名空间能力和映射策略。

映射成功后，权限边界仍然存在

子 user namespace 内的 UID 0 可以获得该 namespace 范围内的一组能力，但这些能力不等于初始 user namespace 的 root 权限。文件访问、挂载、网络配置和其他资源还会受到所属 user namespace、文件系统映射和目标内核接口的共同限制。

判断映射是否合理，重点看三个问题：

最小排查清单

1. 确认目标进程确实位于新建的 user namespace，而不是仍在初始 user namespace。
2. 读取目标进程的 /proc//uid_map 和 /proc//gid_map，按三列解释，而不是只看第一列。
3. 如果 gid_map 被拒绝，先检查 /proc//setgroups 的状态与父命名空间能力。
4. 确认目标 UID/GID 落在映射范围内；越界身份不能用“改数字”的方式补救。
5. 把 user namespace 身份映射和 network namespace 的接口、路由配置分开排查，它们是不同的隔离维度。

相关问题

命名空间内显示 UID 0，是不是已经获得宿主机 root？

不是。它只是在该 user namespace 的身份视角中为 0；是否能执行某项操作，还要看对应资源和父命名空间的权限边界。

为什么只写 uid_map 还不够？

需要组身份的程序还会读取 GID 映射；此外，某些组相关系统调用受 setgroups 状态影响，因此 UID 和 GID 应当作为一组设计。

可以映射任意宿主机 UID 吗？

不能把映射理解成任意改号工具。映射范围、写入者身份、父命名空间能力和内核接口规则共同决定哪些 ID 可以被写入。

总的来说，Linux user namespace 的非 root 映射不是“给普通用户加 root 权限”，而是把两个 user namespace 的身份范围用明确三元组连接起来。掌握 uid_map 的方向、gid_map 的前置条件和一次写入边界，才能在容器或隔离任务里准确解释“为什么显示是 0、但宿主机权限仍然有限”。