Linux进程Capabilities以CapEff、CapPrm、CapInh等十六进制位图形式存在于/proc/[pid]/status中，需用capsh --decode或getpcaps解码为可读能力名，并结合具体操作（如bind端口需CAP_NET_BIND_SERVICE）诊断权限缺失，再通过setcap最小化授权。
Linux 进程的 Capabilities 并不直接显示为“有”或“无”的开关，而是以位图形式存在于内核中，可通过 /proc/[pid]/status 中的 CapEff、CapPrm、CapInh 等十六进制字段体现。真正理解一个进程能做什么，关键在于正确转储、解码并关联到具体操作需求。
从 /proc/[pid]/status 提取原始能力值
每个运行中的进程在 /proc 下都有对应的状态文件。核心字段含义如下：
- CapEff：effective 能力位图，内核做权限检查时实际比对的集合
- CapPrm：permitted 能力位图，表示该进程当前“被允许使用”的全部能力（含已放弃但可重新启用的）
- CapInh：inheritable 能力位图，决定 execve 后子进程能否继承这些能力
- CapBnd：bounding set，限制当前进程及其子进程所能获得的最高能力上限
例如查看 tcpdump 进程的能力：
将十六进制能力值转换为可读名称
原始字段是 128 位（16 字节）的十六进制字符串，如 00000000a80425fb。手动解析困难，推荐两种方式：
- 用
capsh --decode=00000000a80425fb直接输出能力名列表（需安装libcap2-bin） - 结合
getpcaps [pid]查看进程当前所有能力的文本表示（更直观，但不区分 E/P/I/B 集） - 对特定程序文件，可用
getcap /usr/bin/ping查其 file-based capabilities
注意：getpcaps 显示的是 effective + permitted 的合并视图，而 capsh --decode 可精确还原任意字段值。
结合行为诊断权限缺失问题
当某个操作失败（如 bind 80 端口失败、无法修改系统时间、抓包被拒），不要急于加 root，先确认是否缺对应 capability：
- 绑定 1024 以下端口 → 检查
CAP_NET_BIND_SERVICE是否在 CapEff 中 - 执行
ping或tcpdump→ 必须有CAP_NET_RAW - 调用
clock_settime()→ 需要CAP_SYS_TIME - 加载内核模块 → 需要
CAP_SYS_MODULE（通常仅限 root 或严格管控）
若发现缺失，可临时用 sudo setcap cap_net_bind_service+ep /path/to/binary 授权，再验证是否解决——这是最小权限修复的典型路径。
理解能力集之间的流转关系
Capabilities 不是静态标签，而是一组动态位图，它们在 execve、fork、setuid 等操作中按规则流转：
- execve 时，新程序的 inheritable 能力必须同时存在于旧进程的 CapInh 和新文件的 CapInh 中，才可能进入新进程的 CapPrm
- effective 能力默认不会自动继承，需显式设置
+e（如setcap cap_net_raw+ep） - bounding set 是硬性天花板，即使文件设置了某能力，若该能力不在 bounding set 中，exec 后也不会出现在 CapPrm 中
这意味着：光给二进制加能力不够，还要确保父进程和内核 bounding set 允许它生效。
