Linux setcap 给程序授予能力后如何检查实际生效范围

我排查 setcap 时最容易踩的坑，是看到 getcap 有输出，就以为程序已经拿到了对应权限。实际情况是：getcap 只证明文件上保存了能力；程序经过 execve 启动后，真正能用多少还要看进程的能力集合、bounding set、no_new_privs 和所在用户命名空间。

一、先分清文件能力与进程能力

setcap 修改的是可执行文件的 security.capability 扩展属性。它描述“这个文件在被执行时可以参与能力计算”，不会把能力即时注入已经运行的 PID。内核在 execve 期间，把文件能力与调用进程原有的 inheritable、bounding 等集合一起计算，才得到新进程的 permitted、effective 等集合。

因此，刚执行完 setcap 后，第一件事不是重启旧进程，而是确认目标文件和文件能力内容：

# 把能力写到测试程序；这里只授予绑定特权端口所需的单项能力
sudo setcap cap_net_bind_service=ep /usr/local/bin/my-daemon

# -v 让检查结果更明确；getcap 读取文件能力，不代表进程已经生效
getcap -v /usr/local/bin/my-daemon

如果目标进程已经运行，旧进程不会因为文件属性变化而自动更新。要检查新属性的影响，必须让相同启动路径重新执行该程序，并记下新 PID。

二、用 getcap 解释文件上的 ep 与 i

常见输出类似 /usr/local/bin/my-daemon cap_net_bind_service=ep。其中 p 是文件 permitted 集合，表示执行计算时可进入新进程的 permitted 集合；i 是文件 inheritable 集合，会与执行者的 inheritable 集合相交；e 不是一组能力，而是一个文件 effective 标志，打开后，执行得到的 permitted 能力会同时进入 effective 集合。

这也解释了两个看似矛盾的现象。第一，文件有 p 不等于进程一定有相同的 e；文件 effective 标志、启动器限制和其他边界都会影响最终结果。第二，文件能力只在执行时参与计算，修改后需要重新启动目标程序；对一个已经存在的 PID 运行 getcap，仍然只是文件级证据。

不需要继续扩大权限时，可用下面的命令回滚文件能力：

# 清除目标文件的全部 file capabilities；执行前确认这是正确的部署副本
sudo setcap -r /usr/local/bin/my-daemon

# 再次读取，空结果只说明文件属性已移除，不替代进程回收检查
getcap -v /usr/local/bin/my-daemon

三、从运行中 PID 检查真正的能力集合

确认实际范围时，把 PID 级输出作为第二条证据链。/proc/PID/status 中的能力值是十六进制位图：CapPrm 是 permitted，CapEff 是当前执行权限检查使用的 effective，CapBnd 是 execve 获得能力的 bounding 上限，CapAmb 是 ambient 集合。下面的命令只读取状态，不假定任何具体输出：

pid="$1" # 传入实际服务 PID，例如从 systemctl status 或进程管理器获取

# 读取四个关键集合；十六进制值需要结合 capsh 解码
grep -E '^Cap(Prm|Eff|Bnd|Amb):' "/proc/$pid/status"

# 逐行取出十六进制位图并转成人类可读的能力名
while read -r name value; do
  printf '%s: ' "$name" # 保留集合名称，避免解码后混淆来源
  capsh --decode="0x$value"
done 

判断时优先看三种关系：目标能力出现在 CapEff，说明当前权限检查可以使用它；只出现在 CapPrm 而不在 CapEff，说明进程拥有可纳入 effective 的许可但当前没有启用；如果文件声明了能力而 CapBnd 没有对应位，execve 获得的范围会被上限掩掉。CapAmb 则是另一条继承路径，不能拿它替代 file capabilities 的判断。

四、遇到范围变小时检查启动边界

如果文件级 getcap 正确、PID 级却没有预期能力，建议按固定顺序定位。先检查进程是否真的由目标文件启动，避免看到了旧 PID 或包装脚本；再检查 CapBnd 是否丢位，以及启动器是否设置了 no_new_privs。内核文档明确说明，no_new_privs 会让 execve 不再通过文件能力给新程序增加 permitted 能力。

接着确认用户命名空间和服务配置。能力是相对于 user namespace 解释的，容器、沙箱、systemd 或其他启动器可能提前收紧 bounding set；同一个二进制在宿主机、容器和服务单元里得到的集合不一定相同。最后再结合 LSM 拒绝日志和程序自己的错误处理判断：CapEff 具备能力，只说明通过了能力层检查，不保证网络命名空间、挂载权限或其他安全策略一定允许动作。

生产排查可以留下四项记录：文件路径和 getcap -v 结果、启动命令和实际 PID、四个 Cap* 位图、启动器对 no_new_privs 与 bounding set 的配置。这样既能证明 setcap 是否写入，也能解释为什么最终生效范围比文件声明更小。

相关问题

为什么 setcap 后重启服务，CapEff 仍然没有目标能力？

先排除服务仍在运行旧二进制或旧 PID，再检查文件 effective 标志、CapBnd 和 no_new_privs。其中任一边界收紧，都可能让文件级配置无法完整反映到进程级集合。

只看 CapPrm 能证明程序当前可以使用能力吗？

不能。CapPrm 是许可上限，当前权限检查使用的是 CapEff；两者都应记录，必要时再看 CapBnd 判断后续 execve 的上限。

参考：https://www.man7.org/linux/man-pages/man7/capabilities.7.html、https://www.man7.org/linux/man-pages/man8/getcap.8.html、https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html