用 sudo setcap "" /path/to/binary 彻底清除二进制文件的所有 capability，引号不可省；getcap 应返回空行或 = ；若失败需检查文件系统是否支持 user_xattr。
怎么用 setcap 清除二进制文件上多余的 capability
直接用 setcap 命令清除，不是“禁用”或“屏蔽”，而是把钉在文件上的 capability 条目彻底删掉。只要没被其他机制（如 systemd 的 CapabilityBoundingSet）动态加回来，清除后该文件运行时就不再自动获得对应能力。
常见错误是误以为 setcap cap_net_raw=-ep /path/to/binary 能“关掉”能力——这语法不合法，setcap 不支持减法操作；它只接受 =+ep（添加）或 =-ep（清空全部）。
- 清空该文件所有 capability：
sudo setcap "" /path/to/binary（注意引号不能省） - 验证是否清空成功：
getcap /path/to/binary应返回空行或/path/to/binary = - 若提示
Operation not supported，说明文件系统不支持扩展属性（如某些 NFS 或 FAT 挂载点），需先确认挂载选项含user_xattr
为什么 getcap 显示有 cap 但进程实际没拿到
因为 capability 是分层生效的：文件上设的只是“允许运行时申请”，最终能否持有，还取决于进程启动时的上下文。最常被忽略的是 NoNewPrivileges=true —— 一旦 systemd unit 或容器 runtime 启用了它，哪怕二进制带 CAP_NET_BIND_SERVICE，运行时也会被内核强制丢弃。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 检查进程实际能力：
capsh --print | grep CapEff（在目标进程里执行）或cat /proc/PID/status | grep CapEff - 若
CapEff全为 0，但getcap显示非空，基本可断定是NoNewPrivileges或SecureBits生效 - systemd 服务中若同时配置了
CapabilityBoundingSet和文件 capability，后者会被前者截断——bounding set 是硬性上限
清理前必须确认的三个依赖点
盲目清除 capability 可能导致服务崩溃，尤其当程序内部逻辑依赖某项能力（比如用 libcap 主动 drop 之后再 raise）时。得先看它到底靠不靠这个能力活着。
- 查源码或文档：是否调用
cap_get_proc()、cap_set_proc()等 libcap 函数？有则大概率真需要 - 看启动方式：是否由 systemd 托管？检查
systemctl show SERVICE | grep -E "(Capability|NoNewPrivileges)" - 试运行对比：清除前用
capsh --caps="cap_net_bind_service+eip" -- sh -c '/path/to/binary && echo ok'测试功能；清除后再试，观察是否报Permission denied（如 bind 低端口失败）
别漏掉 user namespace 里的隐式 capability
在容器或 unshare 环境中，即使你清掉了宿主机二进制的 capability，进程在 user namespace 内仍可能因 UID 映射而拥有等效权限。例如 unshare --user --net /bin/bash 启动的 shell，在其命名空间内默认就有 CAP_NET_ADMIN，无需文件 capability 支持。
- 判断是否在 user ns：
readlink /proc/self/ns/user，输出含user:[12345]即表示已进入 - 此时清除宿主机二进制的 capability 没意义，真正要控的是
/proc/self/status中的CapBnd（bounding set）和 namespace 创建参数 - 加固方向应转向
unshare --user --no-privs或容器 runtimes 的--cap-drop=ALL
capability 不是开关，是映射表；清除文件上的条目只是撕掉一张准入证，但门后有没有人放行，还得看进程落地时的整个权限上下文。最容易被忽略的，就是 systemd 的 CapabilityBoundingSet 和 user namespace 的默认能力授予机制——它们比文件 capability 更底层、更难察觉。
