Linux capabilities 怎样让服务放弃多余权限

服务能启动，不等于它需要保留启动环境的全部特权。我倾向于先给普通后台任务建立“零特殊能力”基线，再逐项讨论例外。本文限定系统级 systemd 服务，不把两项能力配置包装成完整沙箱；示例是配置方案，不是线上实测记录。

配置语义以 systemd.exec 官方文档为准。先对照本机手册与发行版版本，勿直接改生产服务。

先从无需特殊权限的服务开始

假设 archive-worker.service 只读取业务输入、写入归档目录并访问普通网络接口。维护前先确认：专用账户已存在，目录属主、组和读写权限已配好，程序不依赖启动时修改系统配置。如果实际流程需要挂载、修改网络或创建特殊设备，应先拆清职责，不能为了通过启动就放回一大串能力。

独立账户和 capabilities 是不同维度。账户决定普通文件访问身份；能力集合涉及特权操作。即便能力为空，账户原本能读取的数据、已获准访问的服务和普通网络连接也不会自动消失。

分清能力上限与主动授予

CapabilityBoundingSet 约束能力上限，不是给非 root 程序自动发放对应能力；AmbientCapabilities 才用于向启动的程序携带所需的 ambient 能力。不要把“允许保留”误读为“当前已经有效”。配置还要与 User、程序执行行为和现有单元一起理解。

多处正向赋值可能累加，因此覆盖已有设置时，先用空赋值清掉前面的集合，再写确切需要的项目。本文不采用反向排除列表：保留清单更便于解释为何每一项确实存在。执行命令若带有特权前缀“+”，还要单独查看官方的例外语义，不能凭下面的片段推断所有启动辅助命令都受相同限制。

用空集合收紧后台任务

为现有单元新增专用 drop-in，例如 /etc/systemd/system/archive-worker.service.d/60-capabilities.conf。只调整本次讨论的属性，保留原来的 ExecStart、依赖和资源路径。下面的账户名是业务占位，不是要求创建同名账户。

# 后台任务没有特殊能力需求；账户和目录需预先准备
[Service]
User=archive-worker
CapabilityBoundingSet=
AmbientCapabilities=
NoNewPrivileges=yes

前两个空值表示这里采用空集合；NoNewPrivileges=yes 补充限制通过后续 exec 获取新特权的路径，并不代替文件权限配置，也不意味着所有外部授权通道已被封闭。若服务原来以 root 工作，切换 User 本身就可能改变行为，务必在预发布环境先定位依赖。

变更前阅读完整单元与其他 drop-in，留意加载顺序。不能只看自己新建的文件，也不能把启动失败统一解释为“缺 capabilities”：目录不可写、相对路径变化、密钥权限都可能是普通身份问题。

确有需要时只留下单项能力

另一类服务确实需要自行绑定受特权保护的 Internet 端口时，可以讨论 CAP_NET_BIND_SERVICE。它针对端口绑定，不代表网络管理权限；先结合本机端口策略判断是否真的需要，若由 socket 激活或上游代理提供入口，也未必需要把此能力交给应用。能力定义可查 Linux capabilities 手册。

# 仅适用于业务已确认需要该能力的服务
[Service]
User=archive-worker
CapabilityBoundingSet=
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes

这是替代空集合方案的例外示例，不要把两份示例并排作为不同文件长期叠加。新增能力应写明对应的业务动作；若功能仍失败，先核对程序、监听配置和普通权限，不直接扩大到 CAP_SYS_ADMIN 或 CAP_NET_ADMIN。启动辅助程序若也需要能力，说明服务边界还值得重新梳理。

观察新进程并准备回退

# 只读查看当前完整配置，确认其他覆盖文件
systemctl cat archive-worker.service
# 在批准的维护窗口重新加载并重启，重启会中断业务
sudo systemctl daemon-reload
sudo systemctl restart archive-worker.service
# 查看 systemd 记录的属性与主进程编号
systemctl show archive-worker.service -p CapabilityBoundingSet -p AmbientCapabilities -p MainPID

只重新加载配置不会追溯改变旧进程的能力集合。取得新的 MainPID 后，再在允许读取 /proc 的环境观察该进程；下面命令会拒绝空值或 0，不把它们误当有效进程。

# 读取主进程能力字段；进程可能随时退出，失败时重新定位
pid="$(systemctl show archive-worker.service -p MainPID --value)"
case "$pid" in
  ''|0|*[!0-9]*) echo "没有有效主进程编号"; exit 1 ;;
esac
sed -n '/^Cap/p' "/proc/$pid/status"

proc_pid_status 手册区分 CapEff、CapPrm、CapBnd、CapAmb 等字段。CapBnd 不是 CapEff 的同义词；不能只看到上限里有某项就说程序正在使用它。空集合基线下相关字段预期为空位集合，但这里不伪造运行输出；实际值要按目标进程、执行路径和系统环境解释。

服务若派生多个进程或自行调整线程能力，只看 MainPID 不是全面证明。业务验收还应覆盖真实读写、启动辅助流程和必要网络操作。回退时恢复本次专用 drop-in 的原内容，再重新加载并在维护窗口重启；不要一键清除其他人的覆盖配置。我的取舍是：让每项保留能力都有明确理由，而不是用“服务正常”替代权限边界说明。