非root容器安全核心在于User Namespace的UID/GID映射机制：容器内root（UID 0）被内核映射为宿主机非特权UID（如100000），通过/etc/subuid、/etc/subgid配置子ID范围，并由uid_map/gid_map实现内外ID翻译，使容器进程在宿主机上仅具普通用户权限。
非root容器的安全性，核心不在“不加user指令”，而在于linux用户命名空间（user namespace）如何把容器里看似是root的进程，悄悄变成宿主机上一个毫无特权的普通用户。
用户命名空间不是“切换用户”，而是“重映射ID”
很多人误以为USER 1001只是让容器内进程换个身份运行——其实它依赖的是内核级的ID映射机制。容器启动时，Docker会为它创建一个独立的用户命名空间，该命名空间自带两张映射表：/proc/[pid]/uid_map 和 /proc/[pid]/gid_map。
这两张表定义了“容器里写的UID，实际对应宿主机哪个UID”。例如：
-
0 100000 65536表示：容器内 UID 0（即root）→ 映射到宿主机 UID 100000 -
1 1001 1表示：容器内 UID 1 → 映射到宿主机 UID 1001
这个映射关系在容器进程创建之初就已写入，且不可动态修改。一旦建立，容器内所有进程看到的UID/GID都是“虚拟视图”，而内核在做权限检查时，始终使用映射后的宿主机真实ID。
映射规则从哪来？靠 /etc/subuid 和 /etc/subgid
Docker守护进程不会凭空生成映射，它读取宿主机上的两个关键配置文件：
-
/etc/subuid：记录每个系统用户可使用的子UID范围，格式如dockremap:100000:65536 -
/etc/subgid：同理，定义子GID分配范围
当启用用户命名空间（如配置"userns-remap": "default"）后，Docker会自动为dockremap用户分配一段连续UID区间，并用它来填充每个容器的uid_map。这意味着：即使你在Dockerfile里写USER root，只要用户命名空间开启，这个“root”在宿主机上也只是一个编号100000的普通用户，无法写/etc、加载模块或调用mount等特权操作。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
为什么 --user 1001 和 用户命名空间不是一回事？
这是最容易混淆的点：
-
--user 1001是运行时指定容器内进程的有效UID，但它不改变命名空间映射——如果没开启用户命名空间，UID 1001 在宿主机上就是真实的1001，仍可能拥有宿主机上该用户的全部权限（比如能读写/home/1001） - 用户命名空间是更底层的隔离：它让整个容器运行在一个“ID翻译层”之后，无论你用
--user 0还是--user 999，最终都落在预设的子UID区间内，与宿主机真实用户完全解耦
简单说：--user控制容器内“你是谁”，用户命名空间决定“你在宿主机上实际算老几”。生产环境建议两者结合：既在Dockerfile中固定USER，也在Docker daemon.json中启用userns-remap。
权限限制的真实体现：不是报错，而是静默失败
启用用户命名空间后，很多操作不会直接报“Permission denied”，而是返回EPERM或EACCES，因为内核在做能力检查（capability check）时，发现当前进程在宿主机视角不具备对应能力。
- 尝试绑定80端口 → 失败（需要
cap_net_bind_service，但该能力默认不授予非root映射用户） - 挂载tmpfs → 失败（
cap_sys_admin被禁用） - 修改系统时间 → 失败（
cap_sys_time不可用）
这种静默限制比粗暴报错更安全——攻击者无法通过错误信息反推系统状态，只能不断试错，大幅增加逃逸成本。
