传统的Linux权限控制粒度过粗passwd以命令为例，需要修改用户密码root权限，但普通用户应该能够修改自己的密码Linux就使用了SUID、EUID机制，使passwd过程以其所有者为基础root这样，权限运行就可以了root修改密码的权限

SUID机制存在安全隐患，passwd过程只需修改密码，但在整个运行周期中获得root权限一旦出现漏洞，很可能会被利用

所以，Linux内核在2.2后引入了Capabilities机制，细粒度化权限控制，可按需授权

这是文档：https://man7.org/linux/man-pages/man7/capabilities.7.html

首先，Capabilities有一个集合的概念，即一个过程或可执行文件，它能拥有什么特权？

有三种可执行文件Capabilities集合：

当文件执行时，该集合的内容将添加到过程中Permitted集合中

当文件执行后，这个集合会与进程的Inheritable集合位置和操作(&)，确定执行过程execve函数后哪些capabilites可以被继承

这不是一个集合，而是一个位置(bit)，如果此bit设为1，则Permitted集中新增capabilites会在执行execve将函数添加到过程中Effective集合中

• 设置capabilites

setcap [capability,capability,...] [ep] [文件]  # or  setcap [capability ep capability ep ...] [文件] 

capability是特权值， ep代表加入Effective和Permitted集合中

• 获取capabilites

getcap [文件] 

有五种线程(进程)Capabilities集合：

这一集定义了线程所能拥有的特权的上限Inheritable和Effective集合超集

包括当执行execve 函数可以由新的可执行文件继承capabilities（执行execve 添加函数后Permitted集合中）

内核检查特权操作时，实际检查的集合(可在执行操作前增加/删除)Effective中的capabilities，实现临时开/关权限的功能)

这个集合是Inheritable如果某个集合的超集，capability不在Bounding即使它在集合中Permitted集线程不能集中capability添加到它的Inheritable集合，集合execve以后不能添加capabilities

这个集合是Permitted和Inheritable的子集，当Permitted和Inheritable删除某个capability当集合中对应的对应对应也会自动删除capability，子过程将自动继承该集合capabilities，子进程的Permitted、Effective和Ambient都会有这些capabilities

原型：

int capset(cap_user_header_t hdrp, const cap_user_data_t datap); 

文档：https://linux.die.net/man/2/capset

原型：

int capget(cap_user_header_t hdrp , cap_user_data_t datap); 

文档：https://linux.die.net/man/2/capget

typedef struct __user_cap_heaer_struct { 
        
    __u32 version;
    int pid;
 } *cap_user_header_t;

typedef struct __user_cap_data_struct { 
        
    __u32 effective;
    __u32 permitted;
    __u32 inheritable;
 } *cap_user_data_t;

我们用 P 代表执行 execve() 前线程的 capabilities，P' 代表执行 execve() 后线程的 capabilities，F 代表可执行文件的 capabilities，那么：

P’(ambient) = (file is privileged) ? 0 : P(ambient)

P’(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding))) | P’(ambient)

P’(effective)   = F(effective) ? P’(permitted) : P’(ambient)

P’(inheritable) = P(inheritable) [i.e., unchanged]

P’(bounding) = P(bounding) [i.e., unchanged]

我们一条一条来解释：

• 如果用户是 root 用户，那么执行 execve() 后线程的 Ambient 集合是空集；如果是普通用户，那么执行 execve() 后线程的 Ambient 集合将会继承执行 execve() 前线程的 Ambient 集合。

• 执行 execve() 前线程的 Inheritable 集合与可执行文件的 Inheritable 集合取交集，会被添加到执行 execve() 后线程的 Permitted 集合；可执行文件的 capability bounding 集合与可执行文件的 Permitted 集合取交集，也会被添加到执行 execve() 后线程的 Permitted 集合；同时执行 execve() 后线程的 Ambient 集合中的 capabilities 会被自动添加到该线程的 Permitted 集合中。

• 如果可执行文件开启了 Effective 标志位，那么在执行完 execve() 后，线程 Permitted 集合中的 capabilities 会自动添加到它的 Effective 集合中。

• 执行 execve() 前线程的 Inheritable 集合会继承给执行 execve() 后线程的 Inheritable 集合。

这里有几点需要着重强调：

1. 上面的公式是针对系统调用 execve() 的，如果是 fork()，那么子线程的 capabilities 信息完全复制父进程的 capabilities 信息。

2. 可执行文件的 Inheritable 集合与线程的 Inheritable 集合并没有什么关系，可执行文件 Inheritable 集合中的 capabilities 不会被添加到执行 execve() 后线程的 Inheritable 集合中。如果想让新线程的 Inheritable 集合包含某个 capability，只能通过 capset() 将该 capability 添加到当前线程的 Inheritable 集合中（因为 P’(inheritable) = P(inheritable)）。

3. 如果想让当前线程 Inheritable 集合中的 capabilities 传递给新的可执行文件，该文件的 Inheritable 集合中也必须包含这些 capabilities（因为 P’(permitted)   = (P(inheritable) & F(inheritable))|…）。

4. 将当前线程的 capabilities 传递给新的可执行文件时，仅仅只是传递给新线程的 Permitted 集合。如果想让其生效，新线程必须通过 capset() 将 capabilities 添加到 Effective 集合中。或者开启新的可执行文件的 Effective 标志位（因为 P’(effective)   = F(effective) ? P’(permitted) : P’(ambient)）。

5. 在没有 Ambient 集合之前，如果某个脚本不能调用 capset()，但想让脚本中的线程都能获得该脚本的 Permitted 集合中的 capabilities，只能将 Permitted 集合中的 capabilities 添加到 Inheritable 集合中（P’(permitted)  = P(inheritable) & F(inheritable)|…），同时开启 Effective 标志位（P’(effective)   = F(effective) ? P’(permitted) : P’(ambient)）。有 有 Ambient 集合之后，事情就变得简单多了，后续的文章会详细解释。

6. 如果某个 UID 非零（普通用户）的线程执行了 execve()，那么 Permitted 和 Effective 集合中的 capabilities 都会被清空。

7. 从 root 用户切换到普通用户，那么 Permitted 和 Effective 集合中的 capabilities 都会被清空，除非设置了 SECBIT_KEEP_CAPS 或者更宽泛的 SECBIT_NO_SETUID_FIXUP。

Linux Capabilities 简介

Linux的capabilities机制

Linux Capabilities 入门教程：概念篇