如何定位Linux中导致EPERM错误的缺失能力ID？

一、能不能定位内核校验失败的具体能力ID？ #

完全可以，但strace本身不会直接输出缺失的Capability ID，得结合内核审计日志和系统调用上下文来确认：

• 先开启内核审计功能：启动时添加audit=1内核参数，或者临时通过sysctl -w kernel.audit=1开启。当进程因Capability不足触发EPERM时，内核会在审计日志里记录具体的Capability名称（比如cap_net_bind_service）或对应的数值ID。
• 配合strace定位：比如strace抓到bind()系统调用返回EPERM，再去审计日志里搜该进程的ID，就能找到对应的缺失Capability。

二、自动暴露所需能力的方法 #

有几种工具和思路可以帮你自动找出程序需要的最小Capability集：

• 动态监控工具：
  • capmon（来自libcap-ng工具集）：可以实时追踪进程运行时的Capability检查请求，记录哪些Capability被内核校验过，直接帮你定位缺失项。
  • perf工具：通过追踪内核函数cap_capable，用perf record -e kernel:function:cap_capable ./your_program捕获所有Capability校验事件，再用perf report分析，就能看到程序尝试使用的Capability。
• 逐步测试法（可自动化）：
  用capsh先清空所有能力，再逐个添加直到程序正常运行：

  capsh --drop=all --add=cap_setpcap -- -c "./your_program"
  

  每次添加一个可能的Capability，直到EPERM消失，这种方式适合小型程序，也可以写脚本批量测试。
• 审计日志回溯法：
  1. 先给程序临时添加全量Capability：setcap cap_all+ep ./your_program
  2. 运行程序完成目标操作
  3. 查看审计日志，提取程序实际用到的Capability
  4. 裁剪掉未使用的Capability，只保留必要的

三、关键注意点 #

• 静态分析工具（比如scanelf）只能列出程序可能用到的Capability，实际运行时可能只用到其中一部分，动态监控的结果更准确。
• 部分系统调用可能依赖多个Capability，需要结合strace的系统调用上下文和审计日志一起分析，避免漏加。

内容的提问来源于stack exchange，提问作者Boris