运行 Docker 容器时，应用突然提示 Operation not permitted、Permission denied，甚至在升级镜像、宿主机内核或容器运行时后无法启动，问题不一定来自文件权限，也可能是 seccomp 拒绝了应用所需的系统调用。🔐 本文从工作原理、故障识别、定位流程和策略优化四个方面，整理一套可直接执行的排查方法。
一、seccomp 为什么会拒绝系统调用
seccomp 是 Linux 内核提供的系统调用过滤机制，可以限制进程能够调用的内核接口。Docker 默认会为普通容器加载 seccomp 配置，通过允许列表放行常见系统调用，并对未放行的调用返回错误，从而缩小容器攻击面。Docker 官方说明，默认策略通常使用 SCMP_ACT_ERRNO 拒绝不符合规则的调用，应用侧常见表现就是 EPERM 错误。具体机制及默认限制项可参考 Docker seccomp 官方文档。
需要注意的是，seccomp 与 Linux capabilities、AppArmor、SELinux、文件权限属于不同控制层。看到“权限不足”时，不能直接认定是 seccomp；同一个 EPERM 也可能由缺少 CAP_SYS_ADMIN、只读文件系统或强制访问控制规则引起。
二、常见故障场景与现象
- 应用升级后启动失败：新版本开始使用 clone3、io_uring_setup、memfd_create 等系统调用，而当前策略没有放行。
- 跨架构或仿真环境异常：镜像架构、宿主机架构及策略中的 architectures 配置不匹配。
- 自定义策略无法加载：JSON 格式错误、系统调用名称拼写错误，或者策略引用了当前 libseccomp、内核不支持的调用。
- 旧宿主机运行新镜像失败：容器内程序较新，但宿主机内核、Docker Engine 或 libseccomp 版本较旧。
- 普通模式失败而特权模式正常：可能涉及 seccomp，也可能是 capabilities、设备访问或 AppArmor 等限制，需要继续隔离变量。
三、按顺序执行的排查流程
1. 收集容器错误与运行环境
先执行 docker logs 容器名 查看应用日志，再通过 docker inspect 容器名 检查 SecurityOpt、CapAdd、CapDrop、Privileged、ReadonlyRootfs 等配置。同时记录 Docker、内核和 libseccomp 版本，例如执行 docker version、uname -a，避免只根据一条报错下结论。🧭
2. 确认宿主机支持 seccomp
可执行 grep CONFIG_SECCOMP= /boot/config-$(uname -r)。正常情况下应看到 CONFIG_SECCOMP=y；部分发行版没有对应配置文件，也可以通过 docker info 的安全选项以及内核配置来源继续确认。Docker 对内核 seccomp 支持条件的说明见 官方说明。
3. 用临时对照实验隔离问题
在受控测试环境中，以相同镜像和参数追加 --security-opt seccomp=unconfined 运行一次。如果原故障消失，说明 seccomp 是主要嫌疑；如果仍然失败，应继续检查 capabilities、AppArmor、SELinux、挂载权限和设备映射。
安全提示：seccomp=unconfined 会取消该层系统调用过滤，只适合短时间诊断，不应作为生产环境的长期修复方案。
4. 找出被拒绝的具体系统调用
优先检查宿主机审计日志，可使用 ausearch -m SECCOMP -ts recent，或执行 journalctl -k、dmesg 后筛选 seccomp、audit、denied 等关键词。日志通常会包含 syscall 编号、进程、架构和返回动作，可借助系统头文件、ausyscall 或对应架构的系统调用表，将编号转换为名称。
如果审计日志信息不足，可在测试环境使用 strace -f 跟踪应用，重点观察返回 EPERM 或 ENOSYS 的调用。但要留意：strace 显示的是失败结果，并不能单独证明拒绝来源就是 seccomp，仍需结合对照实验和审计记录判断。
5. 检查自定义策略内容
确认配置中的 defaultAction、architectures、syscalls、names、action 和参数条件是否符合预期。若策略采用默认拒绝模式，只应补充应用确实需要的系统调用；若规则包含参数过滤，还要核对 index、value、valueTwo 和 op，防止因参数范围错误造成误拦截。
四、正确修复：最小化放行而非整体关闭
- 从与当前 Docker 版本匹配的默认策略开始，不要随意复制来源不明的宽松模板。
- 根据审计结果，仅增加确认必要的系统调用，并记录其业务用途。
- 使用 --security-opt seccomp=/path/profile.json 加载策略，在预发布环境执行启动、读写、网络、升级和异常恢复测试。
- 如果系统调用还依赖特定 capability，应分别评估，不能用增加大量权限替代精确规则。
- 将策略文件纳入版本控制，记录镜像版本、内核版本、Docker 版本、变更原因和回滚方式。
对于 Kubernetes 场景，还应确认 Pod 的 securityContext 是否指定 RuntimeDefault、Localhost 或 Unconfined，并检查节点上的策略文件是否存在。多节点集群尤其要防止某个节点缺少策略或运行时版本不一致，导致同一工作负载表现不同。
五、容易踩中的排查误区
- 直接开启 privileged：这会同时扩大 capabilities、设备和其他权限范围，虽然可能让应用恢复，却无法证明根因。
- 把所有 EPERM 都归因于 seccomp：应通过关闭单一控制层的对照实验逐项验证。
- 照搬其他机器的策略：内核、架构、libseccomp 和运行时版本差异都可能影响结果。
- 只验证容器能否启动：部分系统调用仅在备份、故障恢复、并发或特定业务路径中触发。
- 长期使用 unconfined：临时绕过不等于修复，会削弱容器最小权限防护。⚠️
总结
Docker seccomp 故障排查的核心思路是：先确认错误现象，再用 unconfined 做短时对照，随后结合审计日志或 strace 定位具体系统调用，最后以最小范围修改策略。不要用 privileged 或永久关闭 seccomp 掩盖问题。将策略版本、宿主机环境和业务测试结果一并管理，才能在保障应用兼容性的同时，保留系统调用过滤带来的安全价值。✅
