Linux user namespace 怎样配合 memory cgroup

如果一台 Linux 主机允许不可信用户创建 user namespace，只做身份隔离还不够。user namespace 让进程在自己的命名空间里拥有一组独立的 UID 和 capability 视角，但它不会自动给每个用户划出一块固定内存。真正的资源边界要交给 cgroup；Linux 内核文档也明确建议，在启用 user namespace 的系统上启用 memory control group，并为不可信用户配置最大内存。

把两件事分开：user namespace 负责“这个进程以谁的身份、在哪个隔离视角里操作”，memory cgroup 负责“这组进程最多能占用多少内存”。管理员先委派 cgroup 子树并设定上限，再让任务进入 user namespace。

• memory.high 是高水位，超过后会进入直接回收和节流压力，但不等于立即 OOM。
• memory.max 是硬上限，回收无法降低使用量时可能在该 cgroup 内触发 OOM。
• memory.events 默认带层级统计，定位当前 cgroup 自身时同时读取 memory.events.local。

官方资料：https://kernel.org/doc/html/latest/admin-guide/namespaces/resource-control.html

先分清 user namespace 和 memory cgroup 的边界

user namespace 解决的是身份映射与 capability 归属。进程可以在新命名空间里看到自己的 UID 映射，也可能获得该命名空间内的 capability；但涉及初始 user namespace 或宿主机全局资源的操作仍受到限制。它并不负责统计一组进程的匿名内存、页缓存、内核数据结构或 TCP 缓冲区。

memory cgroup 则是 cgroup v2 的资源控制器。它沿层级组织进程，父级施加的限制会继续约束子树；即使 cgroup 子树被委派给较低权限的用户，委派者也不能突破祖先 cgroup 的限制。这个组合的关键不是把两个概念混成“更强的 namespace”，而是让身份边界和资源边界分别落在正确的机制上。

准备 cgroup v2 的 memory 控制器

下面的示例假定主机已经挂载 cgroup v2，且管理员在统一层级下创建了可委派的工作目录。先确认根层级是否能看到 memory，再在父 cgroup 的 cgroup.subtree_control 中启用它。非根 cgroup 还要注意“不能一边在目录里放进程，一边用该目录向子目录分发 domain controller”的约束。

# 只读取控制器列表；路径按发行版的 cgroup v2 挂载点调整
cg_root=/sys/fs/cgroup
grep -qw memory "$cg_root/cgroup.controllers" || {
  echo "memory controller is unavailable" >&2
  exit 1
}

# 创建一棵专供隔离任务使用的子树，并让它获得 memory 控制器
workload="$cg_root/untrusted-workload"
mkdir -p "$workload"
printf '+memory\n' > "$cg_root/cgroup.subtree_control"

# 在资源边界内再创建叶子 cgroup，避免把任务直接放在父级控制目录
job="$workload/job-a"
mkdir -p "$job"
printf '384M\n' > "$job/memory.high"
printf '512M\n' > "$job/memory.max"
printf '1\n' > "$job/memory.oom.group"

这段命令表达的是管理员侧配置关系，不应直接照搬到生产主机。写入 cgroup.subtree_control 需要相应权限；如果目录是委派给普通用户的，委派方还必须明确哪些目录和 cgroup.procs、cgroup.subtree_control 文件可写，不能因为进程拥有 namespace 内的 capability 就默认拥有宿主机 cgroup 文件权限。

让隔离任务同时拥有两种边界

任务进入 user namespace 的方式可以是 unshare 或容器运行时；这一步只改变身份和命名空间视角。资源边界要先由管理员设置，再把启动后的进程 PID 写入目标 cgroup，或者使用运行时提供的等价 cgroup 配置。这样，任务即使在自己的 user namespace 里把 UID 映射成命名空间内的 root，也仍然受宿主机 cgroup 的 memory.max 约束。

# 先启动一个拥有独立 user namespace 的工作负载；这里只展示关系，不执行危险操作
unshare --user --map-root-user --mount-proc /usr/local/bin/untrusted-worker &
pid=$!

# 把启动进程放入管理员预先设置的 cgroup，PID 应替换为实际任务标识
printf '%s\n' "$pid" > "$job/cgroup.procs"

# 读取当前使用量与高峰值，确认观察对象确实是这个 cgroup
cat "$job/memory.current"
cat "$job/memory.peak"

生产环境更推荐让容器或服务管理器在创建任务时就确定 cgroup 归属，减少进程启动后再迁移带来的竞态。迁移进程也不会把已经发生的有状态内存“搬运”到新 cgroup；因此 cgroup 的层级和任务归属应在启动设计阶段确定。

用 memory.current 和事件文件判断限制是否生效

排查时不要只看进程是否退出。memory.current 反映当前 cgroup 及其后代的使用量，memory.peak 记录峰值；把它们和 memory.high、memory.max 放在同一目录读取，才能知道是正常运行、进入高水位节流，还是接近硬上限。

# 事件文件按字段名解析，不依赖内核输出的固定行顺序
for file in memory.current memory.peak memory.high memory.max memory.events memory.events.local; do
  echo "--- $file"
  cat "$job/$file"
done

# 保留未知事件字段，兼容内核后续增加新的计数项
while read -r key value; do
  printf '%-18s %s\n' "$key" "$value"
done 

high 增长表示超过高边界后发生节流或直接回收压力，不能单独证明已经 OOM；max 和 oom 表示逼近或触达硬边界的过程；oom_kill 增长才表示有进程被 OOM killer 终止。memory.events 默认可能汇总子 cgroup，若要判断当前叶子自身的事件来源，需对照 memory.events.local 的增量。

常见问题

user namespace 内的 root 能修改 memory.max 吗？

不能据此推断可以。能否写入取决于宿主机 cgroup 的委派权限、目录边界和文件权限；namespace 内的 root 不是初始 user namespace 的 root。

设置 memory.high 后还需要 memory.max 吗？

通常需要。high 更适合提供可监控的节流线索，max 才是最后的硬上限；两者应结合工作负载的峰值和可接受的 OOM 行为设置。

为什么 memory.events 比当前任务看到的事件多？

因为它可能包含子树统计。读取同目录的 memory.events.local，再检查 cgroup.procs 和子 cgroup，才能区分当前层与后代的贡献。