在 Docker 容器中执行 iptables、mount、修改系统时间、调整网卡或访问设备时，经常会遇到 Operation not permitted。这并不一定是文件权限不足，而可能是 Linux Capability、seccomp、AppArmor、SELinux、设备控制或用户命名空间共同限制的结果。🔍 本文从最小权限原则出发，给出一套可落地的定位与裁剪方法。
一、理解 Capability：root 不等于全权限
传统 Linux 权限模型把特权操作集中交给 root，而 Capability 将其拆分为多个独立能力。例如，CAP_NET_ADMIN 用于配置网络接口和防火墙，CAP_SYS_TIME 用于修改系统时间，CAP_NET_BIND_SERVICE 用于绑定特权端口，CAP_SYS_PTRACE 用于跟踪其他进程。
容器内即使显示 UID 为 0，也只拥有运行时授予的 Capability。Docker 默认保留一组常用能力，同时移除风险较高的能力。因此，“容器里已经是 root”不能证明进程具备挂载文件系统、加载内核模块或修改宿主机网络的权限。Docker 的 容器运行命令文档提供了 cap-add 与 cap-drop 参数说明。
二、常见异常与所需能力
- iptables、ip link、路由配置失败：通常需要 NET_ADMIN；抓取原始网络包还可能需要 NET_RAW。
- mount 或部分 FUSE 操作失败：可能涉及 SYS_ADMIN、设备映射及 seccomp。SYS_ADMIN 覆盖范围很广，应谨慎授予。
- date -s 修改时间失败：通常缺少 SYS_TIME，而且容器时间通常与宿主机共享内核时钟。
- strace 附加进程失败：可能缺少 SYS_PTRACE，也可能受进程 UID、Yama 或 seccomp 限制。
- mknod 或访问设备失败：除 MKNOD 外，还要检查 --device 和设备 cgroup 规则。
- chown、setuid 启动失败：应检查 CHOWN、SETUID、SETGID，以及只读文件系统和挂载参数。
Capability 只是授权链中的一层。能力已经添加但错误仍然存在时，不要继续盲目增加权限，应转向 seccomp、LSM、设备和挂载配置排查。
三、推荐的排查顺序
1. 确认失败的系统调用
先记录完整报错、退出码、容器镜像版本和启动参数。可在测试环境中使用 strace 跟踪失败命令，例如执行：strace -f -e trace=%process,%file,%network 命令。重点查找返回 EPERM 的系统调用，再根据调用类型判断可能缺少的 Capability。
2. 查看容器当前能力
进入容器后，可运行 grep Cap /proc/1/status 查看进程 1 的能力集合；若镜像包含 libcap 工具，还可运行 capsh --print 或 getpcaps 1。同时使用 docker inspect 容器名检查 CapAdd、CapDrop、SecurityOpt、Privileged、ReadonlyRootfs 和设备映射，避免只看 Dockerfile 而忽略实际部署参数。
3. 做最小化对照实验
若怀疑缺少 NET_ADMIN，可在隔离测试环境中使用 docker run --cap-add=NET_ADMIN 镜像验证。问题消失只能说明该能力与故障相关，不能直接证明生产环境必须永久授予它，还应确认应用是否可以通过宿主机预配置、Sidecar 或专用服务完成相关操作。
4. 排除 seccomp 与安全模块
Docker 默认 seccomp 配置会限制部分系统调用，并通过权限错误向进程返回结果。可查看 Docker seccomp 官方说明，确认失败调用是否被默认策略拦截。AppArmor 环境可检查内核日志中的 DENIED 记录，并参考 AppArmor 配置文档；SELinux 环境则应检查审计日志和卷标签。🛡️
5. 检查额外边界
设备操作应核对 /dev 节点是否映射及读、写、mknod 权限；文件操作应检查只读根文件系统、卷挂载选项、文件所有者和 nosuid 等标志；Rootless Docker 还受用户命名空间和宿主机配置影响。嵌套容器场景则要同时检查外层容器，因为内层运行时无法突破外层的权限上限。
四、Capability 裁剪的正确姿势
推荐采用“先全部删除，再逐项添加”的方式建立权限基线，例如：docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE 镜像。在 Compose 中可配置 cap_drop: ALL，再通过 cap_add列出确有需要的能力。每增加一项，都应记录对应功能、验证方法和风险说明。
不要把 --privileged当作常规修复方案。它会显著扩大容器可操作范围，还可能改变设备及安全策略约束。更稳妥的做法是先用它进行短时对照测试，确认问题属于权限边界后立即撤销，再定位到具体 Capability、设备或安全策略。
五、上线前的验证清单
- 以实际生产用户启动容器，而不是只用 root 完成功能测试。
- 执行启动、停止、健康检查、网络初始化和数据迁移等完整流程。
- 确认删除某项 Capability 后，核心功能及异常恢复流程仍然正常。
- 检查容器编排配置是否覆盖镜像默认用户或安全选项。
- 保留失败系统调用、安全审计日志和最终授权清单，便于回归排查。
- 将权限配置纳入代码评审，避免临时 cap-add 或 privileged 长期遗留。
总结
处理 Operation not permitted 的关键不是“给更多权限”，而是找出哪一层拒绝了哪个系统调用。建议依次检查进程身份、Capability、seccomp、AppArmor 或 SELinux、设备映射、挂载属性及用户命名空间，再通过最小化实验验证。✅ 最终目标应是让容器获得完成任务所需的最少权限，同时保留可审计、可复现和可回滚的配置。
