linux和docker的capabilities介绍

概述验证环境：centos7 x86/64 内核版本4.19.9 在linux 2.2版本之前，当内核对进程进行权限验证的时候，可以将进程划分为两类：privileged(UID=0)和unprivile

验证环境：centos7 x86/64 内核版本4.19.9

在linux 2.2版本之前，当内核对进程进行权限验证的时候，可以将进程划分为两类：privileged(UID=0)和unprivilege(UID!=0)。其中privileged的进程拥有所有内核权限，而unprivileged则根据如可执行文件的权限(effective UID,effective GID，supplementary group等)进行判断。

基于文件访问的进程权限控制

此时进程执行主要涉及6个ID：Real uID/gID，Effective uID/gID/supplementary group，Saved set-user-ID/saved set-group-ID。下面以不同的user ID为例进行讲解，group ID也是类似的。

supplementary group为user的增补组，例如在添加一个名为usetTest1的user时候，-g执行该user的primary group，-G指定该usetTest1的supplementary groups。使用ID命令可以看到“gID=”后面对应usetTest1的primary group，“groups=”后面对应usetTest1的supplementary groups。supplementary groups可以用与DAC验证

[root@localhost ~]# groupadd newGrp1[root@localhost ~]# groupadd newGrp2[root@localhost ~]# useradd -u 10000 -g root -G newGrp1,newGrp2 userTest1[root@localhost ~]# su userTest1[userTest@localhost root]$ IDuID=10000(userTest) gID=0(root) groups=0(root),1001(newGrp1),1)">1002(newGrp2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

进程的RUID为执行该进程的用户ID，该值通常不需要变更；当判断一个进程是否对某个可执行文件有权限时，需要验证EUID，在没有开启SUID功能时，EUID的值等于RUID；SUID主要用于设置EUID。

在上一步中创建了一个usetTest1用户，可以在/etc/passwd查看该用户的home目录，为/home/userTest1

userTest1:x:10000:0::/home/userTest1:/bin/bash

为验证SUID的功能，su切换到userTest1，并在/home/userTest1下创建一个空文件，可以看到wr.log仅对用户userTest1开放写权限

[userTest1@localhost ~]# touch wr.log
[userTest1@localhost ~]# ll-rw-r--r--. 1 userTest1 root   10 Dec 13 18:50 wr.log

在/home/userTest1下编译一个小程序，用于查看当前进程的RUID，EUID和SUID，并写入wr.log。可以看到getIDs对所有用户开发了可执行权限

#include <stdio.h>#include <stdlib.h>#include <unistd.h>int main(){    uID_t ruID;    uID_t euID;    uID_t suID;    getresuID(&ruID,&euID,&suID);    printf("real_user_ID=%d,effictive_user_ID=%d,saved_user_ID=%d\n",ruID,euID,suID);    uID_t rgID;    uID_t egID;    uID_t sgid;    getresgid(&rgID,&egID,1)">sgid);    printf(real_group_ID=%d,effictive_group_ID=%d,saved_group_ID=%d\nstream;    stream = fopen( wr.log",1)">a+ );    fprintf( stream,%shello );    fclose( stream );    return 0;}

total 20-rwxr-xr-x. 1 userTest1 root 8712 Dec 50 getIDs-rw-r--r--. 1 userTest1 root  554 Dec  getIDs.c-rw-r--r--. 50 wr.log

在userTest1用户下执行getIDs，有如下内容，可以看到其UID为10000，跟创建该用户时设置的值是一样的，RUID=EUID；拉起该进程用户所在的group以及该文件所属的group都是root，所以group的数值显示均为0

[userTest1@localhost ~]$ ./getIDsreal_user_ID=10000,effictive_user_ID=10000real_group_ID=0,effictive_group_ID=0

在同一个host上创建不同组的用户userTest2。

[root@localhost ~]# groupadd -g 20001 newGrp3[root@localhost home]# useradd -u 10001 -g newGrp3 userTest2

切换到用户userTest2，并进入/home/userTest1(可能需要为该目录添加other的rx权限)下执行getIDs，但因为wr.log的用户和组是userTest1:root，而当前用户是userTest2:newGrp3，因此会因为无法打开wr.log出现段错误。同时也可以看到当前进程的RUDI=EUID=10001，即创建userTest2时的UID；RGID=EGID=20001，为创建newGrp3时的GID

[userTest2@localhost userTest1]$ ./10001,1)">1000120001,1)">20001Segmentation fault (core dumped)

SUID的作用就是使可执行文件在不同用户下能以文件拥有者的权限去执行。在userTest1用户下为getIDs添加SUID，此时getIDs文件的权限中user对应的x变为了s

[userTest1@localhost ~]$ chmod 4755 getIDs[userTest1@localhost ~]$ ll-rwsr-xr-x. 15 Dec 19:02 wr.log

切换到userTest2，执行getIDs，此时可以执行成功，RUID没有变，但EUID和SUID变为了userTest1的值，此时EUID被SUID值为了10000。即当前程序使用userTest1的权限（EUID）去写入wr.log，因此不会出错。但使用SUID是有安全风险的，本例中的程序并没有能力影响除了wr.log之外的系统环境，但如果是一个包含很多功能的命令（如mount ip等），对该命令授予使用某个用户的完整权限，很大程度上有权限泄露的风险，因此对文件设置SUID时需要谨慎。

[userTest2@localhost userTest1]$ ./20001

更多关于RUID EUID和SUID的内容参见深刻理解——real user id,effective user id,saved user id in Linux

 

使用capabilitIEs解决上述问题

在linux内核2.2版本之后将基于用户的权限进行了划分，称为capabilitIEs，capabilitIEs是线程相关的，使用时需要在线程上进程设置（完整的capabilitIEs介绍参见capabilitIEs）。那么如何以capabilitIEs解决上述的问题呢？一个简单的办法是改变wr.log的用户和组，这样就不会出现权限问题

对getIDs.c做一个小改动增加一行修改wr.log的用户和用户组的 *** 作，其中10001为usetTest2对应的UID，20001为userTest2对应的GID

#include <stdio.h>/home/userTest1/wr.log);    file * );    fclose( stream );    return ;}

编译上述文件，并使用root用户在userTest1目录下设置getIDs1拥有修改文件用户和组的权限CAP_CHOWN，+ep代表将该权限添加到capabilitIEs的Effective和Permitted集合中(下面介绍)，

[root@localhost userTest1]# setcap cap_chown+ep getIDs1

在userTest2下执行getIDs可以看到可以执行成功，注意到wr.log的用户和组也被修改为了userTest2的用户和组

[userTest2@localhost userTest1]$ ./getIDs1real_user_ID=20001
[userTest2@localhost userTest1]$ ll-rwxrwxrwx. 1 userTest1 root     getIDs-rwxr-xr-x. 1 root      root    8760 Dec 20:08 getIDs1-rw-r--r--. 1 userTest2 newGrp3   30 Dec 09 wr.log

查看getIDs的capabilitIEs，可以看到与设置的一样。最终程序能够运行的原理其实是一样的，即程序的EUID和文件的EUID是一样的。

[userTest2@localhost userTest1]$ getcap getIDs1getIDs1 = cap_chown+ep

更简单的办法是给chown设置capabilitIEs，这样进程执行的时候会获取chown上的capabilitIEs，这样就可以拥有权限去执行。在host上执行下面命令。切换到userTest2时就可以使用chown命令直接修改用户和组。此处不能通过给bash设置cap_chow capabilitIEs来 *** 作，因此此时是非root用户，bash进程在执行chown命令的时候会丢掉所有capabilitIEs，导致缺少capabilitIEs而无法运行

# setcap cap_chown=eip /bin/chown

 

    capabilitIEs介绍

 capabilitIEs可以分为线程capabilitIEs和文件capabilitIEs。线程capabilitIEs包含以下4个capabilitIEs集合：Effective：内核进行线程capabilitIEs检查时实际使用到的集合inheritable：当程序对应的可执行文件设置了inheritable bit位时，调用execve执行该程序会继承调用者的inheritable集合，并将其加入到permitted集合。但在非root用户下执行execve时，通常不会保留inheritable 集合，可以考虑使用ambIEnt 集合，当一个程序drop掉一个capabilitIEs时，只能通过execve执行SUID置位的程序或者程序的文件带有该capabilitIEs的方式来获得该capabilitIEspermitted：effective集合和inheritable集合的超集，限制了它们的范围，因此如果一个capabilitIEs不存在permitted中，是不可以通过cap_set_proc来获取的。当一个线程从permitted集合中丢弃一个capabilitIEs时，只能通过获取程序可执行文件的capabilitIEs或execve一个set-user-ID-root（以root用户权限运行的）程序来获得ambIEnt ：是在内核4.3之后引入的，用于补充inheritable使用上的缺陷，ambIEn集合可以使用函数prctl修改。当程序由于SUID(sgiD)bit位而转变UID(GID)，或执行带有文件capabilitIEs的程序时会导致该集合被清空

线程可以使用3种方式修改capabilitIEs：

fork：子进程使用fork后会继承父进程的capabilitIEscap_set_proc：直接调用系统函数修改，但需要CAP_SETPCAP capabilitIEs权限。在内核2.6.33版本之后，禁止程序直接修改非本进程的capabilitIEs，只允许修改调用者自身进程的capabilitIEs（参见capset）。execve：使用该函数后的capabilitIEs计算方式如下：

P'(ambIEnt)     = (file is privileged) ? 0 : P(ambIEnt)P(permitted)   = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset) | P'(ambIEnt)P(effective)   = F(effective) ? P'(permitted) : P(ambIEnt)P(inheritable) = P(inheritable)

P:执行前的线程capabilitIEs
P':执行后的线程capabilitIEs
F：文件的capabilitIEs

privileged file指设置了capabilitIEs或设置了SUID或sgiD的文件，如果SUID或sgiD被忽略，则上述转换将不会发生

cap_bset为bounding set，主要用来限制拥有CAP_SETPCAP权限的线程通过execve获取文件的permitted capabilitIEs(不影响inheritable集合)，可以看到如果cap_bset为空，它是无法获取到文件的permitted集合，即(F(permitted) & cap_bset)=0。
该特性在内核2.6.25版本前后是不一样的。2.6.25版本之前该特性时系统范围内设置的(通过/proc/sys/kernal/cap-bound)，2.6.25之后是线程范围内设置的，限制了程序可以获得的文件的capabilitIEs。bounding集合可以通
过继承父进程获得，init进程在内核启动后可以获得所有的bounding集合，可以使用prctl来减少bounding集合中的capabilitIEs，但无法添加新的bounding capabilitIEs

F(effective)：当一个程序以set-user-ID-root运行或者进程的EUID为0，这类程序被称为capability-dumb binary，此时程序运行的文件的effective bit会被内核设置为enable。内核在程序运行时会检查该程序是否获得了
capability-dumb binary文件的所有permitted集合，如果没有，返回EPREM错误（通常是因为文件的permitted集合被bound集合过滤导致程序无法获取文件的所有permitted集合）
注：根据公式，线程的permitted集合是可以通过获取文件capabilitIEs扩展的

文件capabilitIEs和线程capabilitIEs共同决定了执行execve之后线程的capabilitIEs。设置文件capabilitIEs需要有CAP_SETFCAP 权限。文件capabilitIEs有如下3种：Effective：为一个标记位，非capabilitIEs集合。如果设置该标记位，执行execve后的新permitted集合中的capabilitIEs都会添加到effective集合中；反之不会添加(参见上述公式中的：P'(effective) = F(effective) ？ P'(permitted) : P'(ambIEnt)）。inheritable：该集合主要是配合线程capabilitIEs集合使用，具体使用方式参见上述公式Permitted：同上

文件的capabilitIEs使用linux 扩展属性来实现(extended attribute，以下简称EA)，EA使用命名空间管理，实现方式比较简单，即key-value方式。文件的capabilitIEs保存在EA的security.capability中，security就是一个命名空间。使用setcap给/usr/bin/的ls目录添加一个capabilitIEs，加入ES，IS和PS中。

# setcap cap_net_raw=eip ls

使用getfattr可以导出该文件对应的EA，"-m -"用于导出所有EA，"-e hex"以16进制方式导出EA

# getfattr -d -m - -e hex ls# file: security.capability=0x0100000200200000002000000000000000000000security.selinux=0x73797374656d5f753a6f626a6563745f723a62696e5f743a733000

可以看到有2个EA，security.capability对应文件的capabilitIEs，另外一个“security.selinux”主要被linux的安全模块调用，实现强制访问控制(MAC)，当然我们可以是使用text方式解码此命名空间的内容，跟使用ls -Z查看的结果是一样的

# getfattr -d -m - -e text system_u:object_r:bin_t:s00"0ls0 ls0ls0struct vfs_cap_data {    __le32 magic_etc;        0 /*0 little endian 0*/0    struct {        __le32 permitted;    0        __le32 inheritable;  0    } data[VFS_CAP_U32];};00x00000100x000001=0x02000010VFS_CAP_REVISION_2的情况，内核代码参见L501。第三个和第四个32位数据时是一样的，因为添加capabilitIEs时指定了=eip，表示permitted和inheritable，同样也是小端序，2000代表的就是0#define main(){    printf(

# hello world\n -Z );    return -rwxr-xr-x. root root system_u:object_r:bin_t:s0       ;}

上面使用hex解码出的security.capability值为0x0100000200200000002000000000000000000000，含5个32位的长度，即0x01000002 00200000 00200000 00000000 00000000，对应以下的结构体，注意其为小端序，转化为大端序为0x0200001 00002000 0002000 00000000 00000000

cp2.630//调用者#include string

第一个32位数值0x0200001的最后一个bit位为1，该bit位就是文件effective的bit位，linux/capability.h中有如下定义(参见代码)

VFS_CAP_FLAGS_EFFECTIVE #include 

在设置文件的capabilitIEs时，内核会根据capabilitIEs的版本(版本的介绍参见capabilities)进行不同处理，同时也会将capabilitIEs 版本号和effective bit位进行位或以及小端序处理（即0x02000000&#undef），这样就得到了上面的0x0200001。内核代码会根据长度优先处理#include cap_net_raw

extern  VFS_CAP_REVISION_2 0x02000000

当执行一个capability-dumb binarIEs(即设置了文件capabilitIEs，但程序本身并没有调用libcap库管理这些capabilitIEs)时，程序会尝试获取所有的文件capabilitIEs，如果获取失败，则返回错误。这主要是为了防止程序缺少某些capabilitIEs而无法运行

写一个小程序验证上述功能，仅用于输出一句话，编译该文件，输出文件名为hello

#include<stdio.h> errno;voID ListCaps(pID_t pID){    uID_t ruID;    uID_t euID;    uID_t suID;    getresuID(head{_liNUX_CAPABIliTY_VERSION_1,pID};    struct __user_cap_data_struct data{};    capget(

为hello添加容器中不存在的capabilitIEs ，将该hello使用如下命令拷贝到容器中执行，会出现“sh: ./hello: Operation not permitted”的错误，因此hello程序会尝试获取文件的cap_mac_admin，但因为容器的bounding集合中不存在该capabilitIEs而获取失败。

# setcap cap_mac_admin=eip hello
# docker head hello c03a:/home

当使用execve执行set-user-ID-root程序时有如下规则：当执行一个set-user-ID-root程序，或程序的RUD或EUID为0时，则该文件的inheritable集合和permitted集合设置为全1当执行一个set-user-ID-root程序，或程序的EUID为0时，则该文件的effective bit设置为1 当线程在不同用户之间进行转换时，有如下规则：
如果线程的RUID，EUID以及SUID的一个或多个为0，当这些UID的值都转变为非0时，permitted,effective,ambIEnt集合都会被清空当线程的EUID从0转变为非0，则程序的effective集合会被清空当线程的EUID从非0转变为0，则permitted集合会被拷贝到effective集合中如果系统用户的UID从从非0转变为0(setfsuid)，则如下capabilitIEs会从effective集合中清除;当系统的EUID从非0转变为0，则permitted集合会被拷贝到effective集合中如果系统UID 从0转变为非0，则如下capabilitIEs会被清空

CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH,CAP_FOWNER,CAP_FSETID,CAP_liNUX_IMMUtable (since linux Cap data ES=0x%x,PS=0x%x,IS=0x%x\n.int),CAP_MAC_OVERRIDE,CAP_MKNOD

当调用capset或cap_set_proc设置程序的capabilitIEs时，必须遵守如下规则：如果调用者没有CAP_SETPCAP ，则新的inheritable必须是现有inheritable和permitted的合集的子集(Since linux 2.6.25)新的inheritable必须是现有inheritable和bounding的合集的子集新的permitted必须是现有permitted的子集新的effective集合必须是现有permitted集合的子集

这样也看出如果现有进程中的permitted中不存在某个capabilitIEs，那么即使该进程有CAP_SETPCAP权限，也不能设置该capabilitIEs。

使用如下程序验证上述部分功能，test.c用于设置当前线程(进程)的capabilitIEs，调用execve执行test1，中间使用getchar()来中断程序，用于手动查看当前程序的capabilitIEs；test1仅查看execv执行之后的capabilitIEs，编译时需要加上-lcap选项，链接cap库

test.c intchar#include <stdio.h>argv){       < error;        .h>int<sys/types.h>stat _POSIX_SOURCE;        pID_t parentPID <sys/capability.h> getpID();        cap_t caps  cap_init();        cap_value_t capList[] &ruID,suID);    struct __user_cap_header_struct { CAP_CHOWN,CAP_SETPCAP,CAP_SETFCAP } ;        unsigned num_caps =4=;        cap_set_flag(caps,CAP_EFFECTIVE,num_caps,capList,CAP_SET);        cap_set_flag(caps,CAP_inheritABLE,CAP_PERMITTED,CAP_SET);        &if,1)">data);    printf( (cap_set_proc(caps)) {                perror(capset() main();                return EXIT_FAILURE;        }        ListCaps(parentPID);        getchar();         argc,char **test1charif 0 error){            printf(=error=%d\n= getpID();        ListCaps(parentPID);        cap_free(caps);        return =;}= 被调用者argv){    ;    pID_t parentPID  getpID();    ListCaps(parentPID);    return ;}首先下载libcap源码wget *argv2[]={git.kernel.org/pub/scm/libs/libcap/libcap.git/snapshot/libcap-2.26.tar.gz2.26 *envp[]={libcap下编译(在libcap.h中引用了一个名为cap_names.h的头文件，但libcap目录下不存在，可以直接从这里拷贝 !=shCAPInh: 00000000a80625fbCapPrm: 00000000a80625fbCapEff: 00000000a80625fbCapBnd: 00000000a80625fb00000000a80625fb0x00000000a80625fb

test1.c 5318#include <stdio.h>CapabilitIEs for=5318: = cap_chown,cap_setfcap+eip

　　上述代码编译方式如下：

sh4.2 https:ID为验证方便，将上述文件放在在libcap-uID/00

使用docker namespace中user namespace中的方式创建一个unprivileged类型的docker容器(有独立的user namespace)

docker run -itd centos:latest /bin/groups

在host上找到对应该进程的PID，可以在/proc/$PID/task/TID/status中查看进程的capabilitIEs信息，截图如下

0

可以使用capsh来解析上述值

# capsh --decode=4.2testreal_user_ID=cap_chown,cap_dac_overrIDe,cap_fowner,cap_fsetID,cap_kill,cap_setgID,cap_setuID,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_rawio,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap

当前也可以通过容器启动进程/bin/sh映射到host上的pID查看对应的capabilitIEs

# getpcaps Cap data ES0x800001030x80000103 `0000000080000103CapPrm: 

将编译好的test和test1拷贝到创建的容器中，当前用户ID如下

CapEff: -CapBnd: 00000000a80425fbCapAmb: # 00000000000000000x80000103=real_user_ID(root) gID=0xa80425fb(root) ps=efUID         PID   PPID  C STIME TTY          TIME CMD(root)

执行./test可以看到如下信息，当前进程(执行execev之前)的capabilitIEs如下，由于进程此时由于getchar()中断，使用上述方式查看当前进程的信息如下(虽然该进程的所有uID为0，但其并不是一个真正系统级别的UID，其UID经过了user namespace的映射，映射到/etc/subuID）

captest     # ./204=203=0,PS=22

CAPInh: 3730000 bash

回车，看到完整的信息如下，虽然test1没有设置文件capabilitIEs，但由于test1的uID都是0，仍然会部分遵守上述提到的"当执行一个set-user-ID-root程序，或程序进程的RUD或EUID为0时，则该文件的inheritable集合和permitted集合设置为全1"的规则(没有全部继承是受bounding集合的限制)

CAPInh: 00000000a80425fbCapPrm: 0000000000000000=0000000000000000,1)">0x80000103

当执行一个set-user-ID-root程序，或程序进程的RUD或EUID为0时，则该文件的inheritable集合和permitted集合设置为全1当执行一个set-user-ID-root程序，或程序进程的EUID为0时，则该文件的effective bit设置为1

在容器中创建一个新的用户，其用户和组都是captest，并修改test和test1的用户和组

useradd captest
chown captest:captest test*
chmod 777 test*

切换到captest用户下执行./test会返回”capset(): Operation not permitted“的错误，查看该用户的进程

[captest@78d4c79e2648 home]$ 21 -53100    su   captest 00:如果程序的RUID，EUID以及SUID的一个或多个为0，当这些UID的值都转变为非0时，permitted,ambIEnt集合都会被清空当程序的EUID从0转变为非0，则程序的effective集合会被清空 pts/test1real_user_ID    1001:0x0    } data[VFS_CAP_U32];    __le32 rootID;};

查看上述bash进程的capabilitIEs信息如下，可以看到effective集合被清空了，这样就导致bash下的子进程的effective集合也是空，没有权限执行。

8”，则CAP_SETPCAP 的值为2^8=256docker可以在run的时候使用--cap-add为容器的初始进程添加capabilitIEs，--cap-drop移除capabilitIEs

bash进程的父进程为“su captest”，其EUID为root，即0，该进程会执行bash命令，即EUID从0 转变为非0。

root      203    186  0 : pts/     captest   204     bash

上述现象符合如下规则

 在captest用户下执行./test1，同样也可以看到，由于udi全部非0，ES和PS都会清空，但IS没有变

[captest@78d4c79e2648 home]$ ./=,1)">1001,1)">0xa80425fb

在内核4.14版本的时候引入了一个namespaced file capabilitIEs的概念，主要用于解决VFS_CAP_REVISION_2下file capabilitIEs无法在不同user namespace下隔离的问题。在VFS_CAP_REVISION_3版本之前，一个CAP_SETFCAP进程可以在获取file capabilitIEs权限的时候，并不关心该进程所在的user namespace，如果一个进程拥有CAP_SETFCAP的权限，那它可以通过设置并执行多个file capabilitIEs来获取原来没有的capabilitIEs权限，这样就导致进程权限完全不受user namespace的限制且毫无意义(既然自己可以设置capabilitIEs并通过exec获得，那文件自身拥有的capabilitIEs就没用了)。因此在4.14版本新增了一个rootID的变量，rootID是指新创建的命名空间中的UID 0对应初始user namespace的UID的值，即映射到host主机上的user ID的值(/etc/subuID)

struct vfs_ns_cap_data {    __le32 magic_etc;    struct {        __le32 permitted;    /* little endian */        __le32 inheritable;  /* little endian */

 

    TIPS 

capabilitIEs只是给了线程执行某项功能的能力，但线程是否能调用另外的程序，需要看当前线程的EUID是否与文件的EUID对应，且能获取该文件的所有capabilitIEs(如果文件设置了capabilitIEs)execve与fork不一样，它并不会创建一个子进程，execve执行程序的时候会对capabilitIEs进行重新计算，如果此时的程序uID不为0或文件capabilitIEs为空，则该程序会失去所有的capabilitIEs。不要轻易给一个线程或文件设置CAP_SYS_admin权限，CAP_SYS_admin的权限类似root在容器中给文件设置capabilitIEs时可能会出现“Operation not permitted”的错误，可以查看host的系统日志，centos上一般时SElinux功能没有关闭导致的，执行setenforce 0即可 capabilities中定义了各个capabilitIEs的值，但要注意这些值代表的是2的幂次方，如“#define CAP_SETPCAP 使用CAP_SETFCAP可以为文件设置任意capabilitIEs，使用CAP_SETPCAP则需要按照一定的规定添加（见上文）一个线程的capabilitIEs集合与自身设置和文件capabilitIEs设置相关，同时也受uID的限制。切换系统用户其实也是执行一个进程（sh或bash）

参考：

http://man7.org/linux/man-pages/man7/capabilitIEs.7.HTML

https://raesene.github.io/blog/2017/08/27/linux-capabilitIEs-and-when-to-drop-all/

https://revIEw.lineageos.org/c/lineageOS/androID_kernel_samsung_apq8084/+/192902/6

https://github.com/riyazdf/dockercon-workshop/tree/master/capabilitIEs

https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilitIEs

https://s3hh.wordpress.com/2017/09/20/namespaced-file-capabilitIEs/

总结

以上是内存溢出为你收集整理的linux和docker的capabilities介绍全部内容，希望文章能够帮你解决linux和docker的capabilities介绍所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。