命名空间本身不直接控制数据访问权限，而是通过隔离资源视图为权限控制提供基础；真正限制容器内进程读写文件需协同User Namespace（实现UID映射）、Mount Namespace（隔离挂载点）和文件系统权限三者——缺一不可。
命名空间本身不直接控制“数据访问权限”，而是通过隔离资源视图，为权限控制提供基础环境。真正限制容器内进程能否读写特定文件或目录，需结合 User Namespace（用户ID映射）、Mount Namespace（挂载点隔离）和文件系统权限三者协同实现。单纯启用命名空间无法阻止容器内 root 修改宿主机文件——关键在如何配置与组合。
User Namespace：让容器 root 失去真实特权
这是数据访问权限隔离的起点。没有它，容器内 UID 0 就是宿主机 root，可任意访问所有文件。
- 启用方式：Docker 默认开启（检查
docker info | grep "userns"），Podman 默认启用；若手动使用unshare，加--user --map-root-user即可创建映射 - 核心机制：将容器内 UID 0 映射为宿主机上一个普通、无特权的 UID（如 100000），该 UID 在宿主机上对绝大多数目录无写权限
- 前提条件：宿主机必须预先在
/etc/subuid和/etc/subgid中为运行容器的用户分配子 ID 范围，例如：alice:100000:65536 - 效果：即使容器内进程以 root 身份运行，也无法修改宿主机上
/etc/passwd或/var/log等受保护路径——因为其实际 UID 在宿主机层面不具备对应权限
Mount Namespace：切断对敏感路径的可见性
仅靠 User Namespace 不够——如果容器仍能看见并挂载宿主机的 /proc、/sys 或根文件系统，就可能绕过权限检查或获取敏感信息。
- 默认行为：Docker/Podman 启动容器时自动创建独立 Mount Namespace，但需主动避免挂载危险路径
- 安全实践：
- 禁止挂载
/proc、/sys、/dev到容器内，或仅以只读方式挂载（--read-only+--tmpfs /tmp） - 用
--volume显式声明所需目录，而非递归绑定整个父目录（如避免-v /home:/home，应限定为-v /home/alice/data:/data:ro） - 启动时添加
--read-only参数，强制根文件系统不可写，再按需用--tmpfs或-v开放特定可写路径
- 禁止挂载
- 验证方法：进入容器后执行
findmnt，确认挂载树中不含意外暴露的宿主机路径
文件系统权限与 UID/GID 映射一致性
常见错误是容器内应用创建的文件，在宿主机上变成“不可读”或“不可写”——根源在于 UID/GID 映射后，文件属主与容器内用户不匹配。
- 问题场景：容器内非 root 用户（UID 1001）创建文件，该 UID 在宿主机映射为 101001；若宿主机目录权限为
755且属主不是 101001，则宿主机无法访问 - 解决办法：
- 启动容器前，确保目标挂载目录的属主 UID 与容器内用户映射后的宿主机 UID 一致（如
chown 101001:101001 /host/data） - 在 Dockerfile 中使用
USER 1001指令，并配合groupadd -g 1001 app && useradd -u 1001 -g 1001 app显式建用户 - 对多租户场景，为每个租户分配独立 subuid 范围，并用不同 UID 运行容器，避免跨租户文件权限混淆
- 启动容器前，确保目标挂载目录的属主 UID 与容器内用户映射后的宿主机 UID 一致（如
- 调试技巧：在容器内外分别执行
ls -n，对比文件 UID 数字是否与预期映射关系一致
补充加固：Capabilities 与只读挂载协同
即便有了命名空间隔离，容器内进程若拥有 CAP_DAC_OVERRIDE 或 CAP_SYS_ADMIN，仍可绕过常规文件权限检查。
- 默认策略：Docker/Podman 已丢弃大部分危险能力，无需额外操作
- 禁用高危能力：
- 绝对避免
--privileged或--cap-add=ALL - 慎用
--cap-add=SYS_ADMIN（等同于 root 权限）；如需挂载，优先用--mount type=bind由运行时处理 - 确需能力时，只加最小集合，例如
--cap-add=NET_BIND_SERVICE用于绑定低端口
- 绝对避免
- 强化挂载：配合
--read-only使用--tmpfs /run --tmpfs /var/tmp，确保运行时临时目录不落盘，进一步缩小攻击面
