为什么大多数Linux发行版依赖`sudo`而非使用capabilities机制？

你提的这个问题戳中了很多系统安全爱好者的痛点——从理论上看，基于capabilities的细粒度权限控制确实比sudo这种「一把梭」的全root权限要更安全，但主流发行版依然坚持用sudo作为核心的权限提升工具，主要是出于几个非常实际的考量：

1. 易用性与兼容性的压倒性优势 #

sudo已经存在了几十年，几乎所有类UNIX系统都支持它，从普通用户到资深管理员都熟悉它的配置逻辑（比如编辑/etc/sudoers或/etc/sudoers.d/下的规则）。而capabilities的使用门槛要高得多：你得给单个二进制文件设置cap位（比如setcap cap_net_admin+ep /path/to/binary），还要处理权限继承、环境变量隔离、文件系统权限等一堆细节，稍有不慎就会导致权限失效或者滥用。

举个例子，你想让用户通过某个工具修改iptables规则，用sudo只需要在sudoers里加一行规则，而用capabilities得专门封装一个二进制、配置组权限、处理子进程权限继承，步骤繁琐到普通用户根本不想碰。

2. sudo本身就能实现细粒度权限控制 #

你可能误以为sudo只能授予全root权限，但实际上它的配置可以精细到「允许某个用户仅运行特定命令，甚至带特定参数」。比如你想让用户foo只能查看和添加特定的iptables规则，完全不需要切换到root shell，只需要在sudoers里写：

foo ALL=(ALL) NOPASSWD: /sbin/iptables -L, /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT

这种配置方式既实现了类似capabilities的最小权限原则，又比直接操作capabilities简单百倍，还能通过sudo日志清晰追踪用户的操作。

3. Capabilities的边界与继承问题太棘手 #

Capabilities是绑定在进程上的，而非用户身份，这会带来很多意想不到的坑：比如你给一个脚本加了cap，但脚本调用的子进程默认不会继承这些权限；有些工具会主动丢弃capabilities以保证安全，导致你的配置失效；甚至不同文件系统对cap位的支持都不一样（比如某些网络文件系统不保存cap属性）。

而sudo是基于用户身份切换的，切换到root后整个会话的权限是一致的，用户不用操心进程间的权限传递问题，用起来更省心。

4. 生态工具的适配度不足 #

绝大多数系统工具和服务在设计时，要么默认假设自己以root运行，要么以普通用户运行，很少考虑用capabilities做权限拆分。比如virsh依赖的libvirt服务需要多个capabilities（网络、存储、设备管理等），你要是想给virsh单独配置这些cap，得逐一梳理依赖，还可能遇到软件本身的兼容性问题——发行版不敢把这种不稳定的方案作为默认配置推给用户。

当然，capabilities也不是没用，它适合给特定服务做最小权限加固（比如让nginx用CAP_NET_BIND_SERVICE绑定80端口，而不用以root运行），但作为日常的管理员权限管理工具，它的适配成本太高。

5. 用户习惯与培训成本 #

这么多年来，「用sudo执行管理员操作」已经成为Linux用户的肌肉记忆。如果发行版突然切换到capabilities为主的模式，用户得重新学习一堆新命令、配置方法和排障技巧，发行版的技术支持成本会飙升。对普通用户来说，与其折腾复杂的cap配置，不如继续用熟悉的sudo来得高效。

总的来说，capabilities是个好东西，但它更适合特定的安全加固场景；而sudo凭借易用性、灵活性和兼容性，成为了发行版和用户都更愿意接受的权限管理方案。

备注：内容来源于stack exchange，提问作者Ben Little