关键在于启用用户命名空间并配置子UID/GID映射，使容器内root(UID 0)映射至宿主机非特权范围（如100000–165535），需编辑/etc/subuid和/etc/subgid，格式为用户名:起始UID:数量，并确保挂载目录属主匹配映射UID。
要让容器真正与宿主机权限脱钩，关键不是“跑得更快”，而是“映射得更准”——核心在于启用并正确配置用户命名空间（User Namespace），使容器内看似 root 的操作，在宿主机上始终落在非特权 UID/GID 范围内。这一步是 rootless 容器（如 Podman）和 Docker userns-remap 的强制前提，不是可选项。
必须配置子 UID/GID 映射池
仅靠 Docker 或 Podman 启动参数无法实现彻底隔离，底层依赖 `/etc/subuid` 和 `/etc/subgid` 文件定义的映射范围。系统据此知道：当前普通用户（如 alice）可在自己的用户命名空间中，把容器内 UID 0–65535 映射到宿主机的 100000–165535 这段非特权区间。
- 执行命令直接添加：
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 alice - 或手动编辑文件：
/etc/subuid 中加一行：alice:100000:65536
/etc/subgid 中加一行：alice:100000:65536 - 格式必须严格：用户名:起始UID:数量，不能有空格、注释、重复行
验证映射是否被内核识别
配置后需重新登录或重启会话，再检查是否生效：
- 运行 podman info | grep -A 5 'host\.users'，应看到类似：
"subuid": ["alice:100000:65536"] - 启动容器：podman run --rm alpine id，输出仍是 uid=0(root) gid=0(root)——这说明容器内是 root，但已受控映射
- 在容器内创建文件后退出，用 ls -n 查看宿主机对应路径，文件属主 UID 应落在 100000–165535 区间，而非 0 或 1000
挂载目录需匹配映射后的 UID
子 UID 配置只是授权“能映射”，不代表宿主机目录自动可写。若容器需读写挂载卷，必须让该目录对映射后的 UID 可访问：
- 推荐做法：将目录属主设为子 UID 起始值
sudo chown 100000:100000 /host/data - 或通过辅助组方式：创建专用 GID（如 100001），把用户加入该组，并设置目录属组 + sgid 位，确保新建文件继承组权限
- 避免直接 chmod 777，那会绕过最小权限原则
配合运行时限制强化边界
用户命名空间解决“身份伪造”问题，还需叠加其他机制堵住旁路：
- 禁用特权模式：不使用 --privileged，需要设备访问时逐项添加 Capability（如 --cap-add=SYS_ADMIN 仅当真需挂载）
- 限制能力集：--cap-drop=ALL --cap-add=NET_BIND_SERVICE，按需精确授权
- 挂载只读根文件系统：--read-only，仅对日志、临时目录用 --tmpfs 或显式可写卷
- 网络隔离：使用自定义 bridge 网络，禁用容器互通（--icc=false），暴露端口绑定到 127.0.0.1 而非 0.0.0.0
