User Namespace通过内核级UID/GID映射实现卷权限安全隔离：需全局启用userns-remap，手动将宿主机挂载目录属主设为映射起始UID，并确保镜像USER或运行时--user指令在映射范围内。
用 user namespace 隔离技术管理 docker 卷权限，核心是让容器内用户（包括 root）在宿主机上始终以非特权身份操作挂载目录，从根源上阻断越权写入或提权风险。它不依赖应用层配置，而是由内核级映射机制保障，比单纯用 --user 或修改镜像 user 更底层、更可靠。
启用 user namespace 映射是前提
必须先全局开启 Docker 的用户命名空间重映射，否则卷权限仍走默认 UID 透传路径：
- 编辑
/etc/docker/daemon.json，加入：{"userns-remap": "default"} - 重启服务：
sudo systemctl restart docker - Docker 会自动创建
dockremap用户，并在/etc/subuid和/etc/subgid中分配一段子 ID 范围（如dockremap:100000:65536） - 此后所有容器内 UID 0（root）都映射为宿主机 UID 100000 起始的普通用户，无法访问真实 root 资源
宿主机挂载目录属主必须匹配映射后 UID
这是最关键的适配动作。若忽略，容器对绑定挂载（-v）目录将无读写权限，报 Permission denied：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 查出当前 remap 起始 UID：运行
awk -F':' '/dockremap/ {print $2}' /etc/subuid，通常返回100000 - 把宿主机目标目录属主设为该 UID/GID：
sudo chown -R 100000:100000 /host/data - 如果使用自定义 remap 用户（如
"userns-remap": "myuser"），则用id -u myuser查起始值，再 chown - 注意：Docker 不会自动帮你改目录权限，这步必须手动完成，且需在启动容器前执行
镜像内 USER 指令仍有效，但含义已升级
原有基于 UID 的权限控制逻辑不变，但在 UserNS 下获得双重防护：
- Dockerfile 中写
USER 1001，容器内进程 UID 是 1001；启用 UserNS 后，它实际对应宿主机 UID100000 + 1001 = 101001 - 这意味着即使镜像硬编码了 UID，也不会与宿主机真实用户冲突，也避免了因 UID 碰撞导致的意外覆盖
- 运行时用
--user 1001覆盖，效果同理——映射后的宿主机 UID 仍是偏移值，安全边界不变 - 所以不必为适配 UserNS 修改已有镜像，只需确保挂载目录属主对齐 remap 范围即可
避开不兼容场景，守住安全底线
UserNS 提供强隔离，但有明确限制，绕过它们等于主动放弃保护：
- 禁用 --privileged：特权模式与 UserNS 互斥，启用后容器启动直接失败，这是设计使然，不可妥协
-
慎用高危 capabilities：如
CAP_SYS_ADMIN在 UserNS 下可能受限或失效，应按需显式--cap-drop - 构建过程不享受 UserNS：docker build 运行在宿主机命名空间中，只有 docker run 才启用映射，因此构建阶段仍需注意基础镜像安全性
- 网络、PID 等命名空间不受影响：UserNS 只管 UID/GID 映射，其他隔离照常，可单独调优
