docker通过user namespace将容器内root映射为宿主机普通uid（如100000），需配置daemon.json启用userns-remap，调整挂载目录属主，并配合dockerfile中user指令实现双重降权。

在 Docker 中用 User Namespace 实现容器内 root 用户降权，核心不是让容器“不用 root”，而是让这个 root 在宿主机上变成一个普通数字——比如 UID 100000。它在容器里仍是 root（uid=0），但在宿主机上没有 root 权限，无法修改关键系统文件、加载模块或接管其他进程。

配置 Docker 守护进程启用映射

这是整个机制的前提，必须全局开启：

• 编辑 /etc/docker/daemon.json，加入：
  {"userns-remap": "default"}
• 保存后执行 sudo systemctl restart docker（注意：reload 不生效，必须完整重启）
• Docker 会自动创建系统用户 dockremap，并在 /etc/subuid 和 /etc/subgid 中分配一段子 ID 范围，例如：
  dockremap:100000:65536
  表示容器内 uid 0 → 宿主机 uid 100000，uid 1 → 100001，依此类推
• 若自动创建失败（如最小化系统），可手动添加：
  sudo useradd -r -u 100000 dockremap
echo 'dockremap:100000:65536' | sudo tee -a /etc/subuid /etc/subgid

适配挂载目录的属主权限

User Namespace 启用后，容器内进程对宿主机文件的访问，实际使用的是映射后的 UID/GID。如果挂载目录属主没对齐，就会出现 Permission denied：

BetterYeah AI

BetterYeah AI是一款面向企业的一站式 AI Agent 应用开发平台。

下载

• 查映射起始 UID：
  awk -F':' '/dockremap/ {print $2}' /etc/subuid（通常为 100000）
• 将绑定挂载的宿主机目录属主设为该 UID：
  sudo chown -R 100000:100000 /host/data
• 即使镜像中用了 USER 1001，该 UID 也会被整体偏移成 101001，不影响应用逻辑，但属主仍需按映射基址调整

避免与特权操作冲突

User Namespace 的设计目标是限制权限，因此天然排斥高危能力：

• --privileged 会被直接拒绝，启动时报错 “userns-remap is enabled”
• --cap-add=CAP_SYS_ADMIN 等接近 root 的 capability 基本无效，不建议添加
• 若需调用 Docker API（如挂载 /var/run/docker.sock），需额外确保容器内 GID 映射到宿主机 docker 组的 GID，否则连接失败

配合镜像内 USER 指令做双重降权

User Namespace 是运行时隔离，USER 指令是构建时加固，两者叠加效果更扎实：

• 在 Dockerfile 中显式创建非 root 用户并切换：
  RUN addgroup -g 1001 appgroup && adduser -u 1001 -G appgroup -D appuser
USER appuser
• 这样容器内默认以 UID 1001 运行；User Namespace 再将其映射为宿主机上的 101001，既脱离 root 上下文，又受命名空间限制
• 相比只用 USER 指令，这种组合能防住更多逃逸路径，比如某些利用内核漏洞提权到容器 root 后的横向操作