在 Docker 中，容器里的进程即使显示为 root，也不等于拥有宿主机 root 的全部权限。常见现象包括 iptables 报“Permission denied”、mount 返回“Operation not permitted”、抓包失败、无法修改系统时间或访问设备。此类问题通常与 Linux Capability、seccomp、AppArmor/SELinux、设备映射及命名空间共同相关。排查时不要一看到权限错误就启用 --privileged，更稳妥的做法是先定位缺失的最小权限，再进行针对性授权。🔐
一、理解 Capability 权限模型
Linux Capability 将传统 root 特权拆分为多个可独立控制的能力单元，例如 CAP_NET_ADMIN 用于部分网络管理操作，CAP_NET_RAW 涉及原始套接字，CAP_SYS_TIME 用于修改系统时间，CAP_SYS_PTRACE 与进程跟踪相关。Capability 是进程或线程的安全属性，并不是“容器账户权限”的简单别名，详细定义可参考 Linux capabilities 手册。
Docker 默认只保留一组相对常用的 Capability，而不是把全部能力交给容器。启动参数 --cap-add 用于增加能力，--cap-drop 用于删除能力。官方建议优先通过这两个参数进行细粒度控制，相关行为可查看 Docker 运行时权限文档。🧩
二、从错误现象判断可能缺少的权限
- iptables、路由或网络接口配置失败：通常先检查 CAP_NET_ADMIN；如果程序需要原始套接字或执行 ping、抓包，还可能涉及 CAP_NET_RAW。
- 绑定低端口失败：可能需要 CAP_NET_BIND_SERVICE，但也要检查进程是否以非 root 用户运行，以及系统对非特权端口范围的配置。
- mount 或 namespace 操作失败：可能涉及 CAP_SYS_ADMIN，但该能力覆盖面很广、风险较高，不能因为名称模糊就直接添加。
- 调试其他进程失败：检查 CAP_SYS_PTRACE，同时确认目标进程是否位于可见的 PID 命名空间中，以及 seccomp、Yama 等机制是否阻止操作。
- 设备访问失败：除了 Capability，还要确认设备是否通过 --device 映射、设备节点权限是否正确，以及设备 cgroup 规则是否允许访问。
三、按顺序执行排查
- 记录完整错误。区分“Permission denied”“Operation not permitted”“Read-only file system”和“Device not found”。不同信息分别指向文件权限、能力或安全策略、只读挂载、设备未映射等问题。
- 确认容器启动配置。执行 docker inspect 容器名，重点查看 CapAdd、CapDrop、Privileged、SecurityOpt、ReadonlyRootfs、Devices、User、Binds 和 Mounts，避免只在容器内部观察。
- 检查实际能力集。容器内可执行 grep Cap /proc/1/status；若安装了 libcap 工具，还可使用 capsh --print 或 getpcaps 1。注意 PID 1 与当前 shell 可能拥有不同能力。
- 开展最小化对照测试。在可控的测试环境中临时增加一个候选能力，例如 docker run --cap-add=NET_ADMIN 镜像。如果故障仍在，应继续检查安全策略，而不是盲目追加更多能力。
- 查看宿主机日志。使用 dmesg 或 journalctl 搜索 denied、apparmor、avc、seccomp 等关键字。SELinux 拒绝通常会出现 AVC 记录，AppArmor 拒绝也可能写入内核或审计日志。🔎
四、Capability 正确裁剪方法
对于用途明确的服务，可以采用“默认全部删除，再按需增加”的方式，例如启动参数使用 --cap-drop=ALL --cap-add=NET_BIND_SERVICE。这比依赖 Docker 默认能力集合更容易审计，也能避免镜像更新后新增组件意外利用不必要的权限。
裁剪前应逐项验证启动、健康检查、正常请求、日志轮转、优雅退出和故障恢复。某些能力只在初始化阶段使用，如果应用支持，可以让启动程序完成初始化后主动降低权限；同时结合非 root 用户、只读根文件系统、禁止提权选项和受控挂载，形成多层防护。
特别警惕 CAP_SYS_ADMIN。它关联大量系统管理操作，授权范围远超单一功能需求。若只是访问某个设备、调整一项网络配置或挂载特定目录，应优先寻找更窄的 Capability、设备映射或宿主机侧预配置方案。⚠️
五、为何添加 Capability 后仍然失败
Capability 只是权限链条中的一环。Docker 默认 seccomp 配置可能阻止特定系统调用；AppArmor 或 SELinux 可能限制文件、设备和内核接口；用户命名空间会改变容器 UID 与宿主机 UID 的对应关系；只读挂载会让具备能力的进程仍无法写入；rootless Docker 也受宿主机非特权用户权限边界限制。
因此，“容器内是 root”或“已经 cap-add”都不能单独证明操作一定成功。还应核对目标路径的属主和挂载参数、宿主机内核是否支持相关功能、系统调用是否被过滤、设备是否真实存在，以及操作影响的是容器命名空间还是宿主机命名空间。
六、谨慎使用 privileged 模式
--privileged 会显著扩大容器权限，并放宽设备及部分安全限制。它可以作为隔离测试环境中的短时诊断手段：如果普通模式失败而 privileged 模式成功，说明问题大概率位于权限或安全策略层，但这并不能证明生产环境应该长期启用 privileged。
正确做法是利用该对照结果继续缩小范围，依次验证 Capability、设备映射、seccomp 和强制访问控制策略，最终恢复为最小授权配置。生产环境还应记录授权原因、责任人、验证用例和复查日期，避免临时权限永久遗留。🛡️
总结
Docker 特权操作失败的排查核心是“分层定位、最小授权”：先确认错误类型和实际启动参数，再检查进程能力集，随后核对 seccomp、AppArmor/SELinux、命名空间、挂载及设备规则。Capability 裁剪应优先采用 drop all、按需 add 的思路，并通过完整业务测试验证。只有当无法以更小权限满足需求时，才评估更宽泛的授权；不要把 privileged 当作通用修复开关，这样才能兼顾功能可用性与容器边界安全。
