Linux setcap 怎样给程序增加最小网络能力

Linux setcap 可以把所需 capability 写入专用可执行文件，使非 root 用户启动的程序在满足执行环境约束时获得对应能力。若任务只是绑定受保护的低端口，通常应考虑 CAP_NET_BIND_SERVICE，而不是 CAP_NET_ADMIN。不过，最小授权的第一步是确认目标端口在当前网络命名空间内确实需要特权。

面对“内部服务想直接监听 80 端口”的部署需求，我会先把问题拆成端口规则、程序文件和启动方式三件事。文件上写着能力，不等于正在运行的进程已经获得它；低端口能绑定，也不等于接口已经能够从外部访问。下面采用原创部署示例，命令供读者按实际环境使用，本文未执行这些命令。

libcap 官方项目地址：https://sites.google.com/site/fullycapable/

我会先确认是不是低端口权限问题

示例对象是已经部署的专用原生二进制 /opt/netdemo/bin/statusd，由非 root 服务账号运行，目标是在本机绑定 80 端口。这个路径只是示例，程序的监听参数应使用自身文档规定的形式。

Linux 的 net.ipv4.ip_unprivileged_port_start 定义当前网络命名空间中第一个非特权端口，默认值为 1024。低于阈值的端口需要 root 或对应的绑定能力；阈值为 0 时，没有这类受保护端口。容器内的设置可能与宿主不同，应在服务实际所在的命名空间读取。内核端口阈值文档

# 在服务实际运行的网络命名空间内读取，不修改端口策略。
sysctl net.ipv4.ip_unprivileged_port_start
# 使用服务本身的启动日志区分权限拒绝、端口占用和地址不存在。
# 本文不假定 statusd 的参数形式，也不把示例当作已运行结果。

如果问题是端口已被其他服务占用，添加能力不会释放端口；如果应用绑定了本机没有的地址，绑定能力也不负责修正地址。对我来说，这一步的价值是避免把一切 bind 失败都归结为“权限不够”。目标端口高于或等于阈值时，也没有必要仅为绑定动作添加这个能力。

把网络任务缩小到一种能力

capability 是按内核操作划分的权限单元，不是“网络功能从小到大”的几个档位。CAP_NET_BIND_SERVICE 不负责开放防火墙，也不授予修改路由的能力；CAP_NET_ADMIN 则涵盖多种网络管理操作。选择应从失败的具体操作反推。Linux capabilities 操作分类

一个容易忽略的代价是：这个能力并不只允许绑定 80，也不限定只绑定回环地址。目标端口、监听地址和运行账号仍要在应用配置及部署设计中约束。最小“能力种类”不等于已经实现最小“端口范围”。

给专用二进制设置文件能力

我倾向于只对职责明确、内容受部署系统控制的二进制设置文件能力。不要对共享的 Python、Node.js、Shell 等解释器做这种授权：它们可以承载不同代码，授权影响面会远大于一个服务。给脚本文件写属性也不应当作解释器获得能力的可靠方案。

先确认程序已安装、路径指向预期实体、文件和上级目录不可被服务账号任意替换，再由管理员设置。以下命令会将文件能力设置为所示集合，不能理解为在保留一切原有能力的同时添加一项。

# 读取目标文件当前能力，已有授权应先纳入部署记录。
getcap -v /opt/netdemo/bin/statusd
# 仅用于已部署的专用原生二进制；这条命令需要管理员权限。
sudo setcap 'cap_net_bind_service=ep' /opt/netdemo/bin/statusd
# 读取写入后的文件属性；这里只检查文件，不代表进程已获得权限。
getcap -v /opt/netdemo/bin/statusd

p 表示 permitted，e 表示 effective；在文件能力语境下，effective 是执行后是否将获准能力置入有效集的标志，不应把它误读成另一种独立权限。= 是设置表达式中的赋值动作，未列出的能力不会因为“以前加过”就自动保留。i 属于 inheritable 语义，本例不为了凑齐字母写成 eip。libcap 文本表达式说明

setcap 成功时退出码为 0，失败时为 1。遇到不支持扩展属性、没有设置文件能力权限等错误，应处理部署环境与文件系统条件，不应继续宣称授权成功。getcap 用于读取指定文件的能力，-v 会连没有能力的条目也显示出来。setcap 手册、getcap 手册

文件授权与进程权限分开看

文件能力保存在可执行文件的扩展属性中，执行时还要结合进程的 capability bounding set 等条件计算。已有进程不会因为管理员随后对磁盘文件运行 setcap，就即时得到新能力；需要按服务管理方式重新启动目标程序。进程也可能在初始化后主动降低能力。

读者可以在自己的部署环境用 getpcaps 读取目标 PID。下面的 12345 必须替换为实际服务进程，不要把启动 Shell 或包装脚本的 PID 当成最终业务进程。

# 替换为真正运行 statusd 的 PID；不要据此猜测服务已经成功启动。
getpcaps 12345
# 从目标进程状态读取能力集合和 NoNewPrivs 标志，供定位启动环境。
sed -n '/^Cap/p; /^NoNewPrivs:/p' /proc/12345/status

getpcaps 展示进程能力，作用对象与 getcap 不同。读取结果的权限和可见范围取决于当前系统环境；即使文件属性符合预期，也应将它和目标进程的实际状态区分。进程能力读取说明

no_new_privs 已启用时，execve 不会通过文件能力为进程新增 permitted 能力。这是启动环境的限制，不能靠重复 setcap 改变。内核文档还说明，该标志会跨 fork、clone 和 execve 继承，设置后不能取消。这里应调整授权设计或改用已批准的服务启动方案，而不是把关闭保护项当成固定排障步骤。内核 no_new_privs 文档

如果可执行文件所在文件系统使用 nosuid 挂载，或程序处于某些跟踪条件，文件能力也可能不按通常方式授予。execve 手册说明这些执行约束，因此“getcap 有输出但绑定仍被拒绝”并不矛盾。还需要看实际执行文件、容器能力限制和系统访问控制策略。execve 权限处理说明

升级、撤销和服务管理怎样衔接

对我来说，文件能力最容易漏掉的环节是升级交付。部署新文件、替换旧文件或经过不保留扩展属性的打包复制后，不能假设原来的属性依然存在。应把“对最终部署文件设置所需能力”写入受控安装流程，并保留目标路径、所需集合及撤销方式。设置动作应在文件内容与所有者等安装操作完成之后进行。

撤销本例文件授权可使用 setcap -r。它移除文件能力集合，与将集合设为空不是同一操作。下面只处理这个专用文件，不扫描或改动其他程序。

# 移除该文件的能力属性，不影响其他二进制文件。
sudo setcap -r /opt/netdemo/bin/statusd
# 再读取文件状态，避免把空集合与属性不存在混为一谈。
getcap -v /opt/netdemo/bin/statusd

撤销文件属性同样不会主动清除已经运行的进程持有的能力。应根据服务的正常停启流程终止旧实例，再按新的授权配置启动；也不要把权限撤销等同于关闭已经绑定的监听 socket。

若程序只作为 systemd 系统服务运行，我会把服务级授权也纳入比较：AmbientCapabilities=CAP_NET_BIND_SERVICE 负责给合适的服务启动环境提供能力，CapabilityBoundingSet=CAP_NET_BIND_SERVICE 限制允许范围。仅写 bounding set 并不等于给非 root 服务授予该能力。具体配置还要结合 User、已有指令及应用是否再次执行其他程序；不要无分析地把文件能力和 ambient 授权叠加。systemd 服务能力配置

按部署方式选择与常见问题

setcap 能限定只开放 80 端口吗？ 不能，CAP_NET_BIND_SERVICE 的范围不按单个端口授权。限定端口与地址需要应用配置、服务架构等其他控制共同完成。

用了 setcap，服务还需要 root 启动吗？ 本例目标就是由非 root 账号运行，但程序读取配置、写日志和访问目录仍需要相应普通权限；能力没有替应用解决这些访问需求。

getcap 正确，外部访问还是失败怎么办？ 把进程是否启动、监听地址、端口占用和网络可达性分开分析。绑定能力不配置防火墙，也不保证外部路由或服务逻辑正确。

是不是应该给所有网络程序统一加 NET_ADMIN？ 不应该。我的选择标准始终是程序实际需要的内核操作。只为低端口绑定授予网络管理权限，会把一个明确需求扩大成多个不必要的管理能力。