為了執行權限檢查，傳統的 UNIX 實現區分兩種類型的進程：特權進程（其有效用戶 ID 為0，稱為超級用戶或 root），和非特權用戶（其有效 UID 非0）。特權進程繞過所有的內核權限檢查，而非特權進程受基于進程的認證信息（通常是：有效 UID，有效 GID，和補充組列表）的完整權限檢查的支配。

自內核 2.2 版本開始，Linux 將傳統上與超級用戶關聯的特權分為幾個單元，稱為 capabilities （權能），它們可以被獨立的啟用或禁用。權能是每個線程的屬性。

權能列表

下面的列表展示了 Linux 上實現的權能，以及每種權能允許的操作或行為：

• CAP_AUDIT_CONTROL（自 Linux 2.6.11）
  啟用和禁用內核審計；修改審計過濾器規則；提取審計狀態和過濾規則。
• CAP_AUDIT_READ（自 Linux 3.16）
  允許通過一個多播 netlink socket 讀取審計日志。
• CAP_AUDIT_WRITE（自 Linux 2.6.11）
  向內核審計日志寫記錄。
• CAP_BLOCK_SUSPEND（自 Linux 3.5）
  可以阻塞系統掛起（epoll(7) EPOLLWAKEUP，/proc/sys/wake_lock）的特性。
• CAP_CHOWN
  對文件的 UIDs 和 GIDs 做任意的修改（參考 chown(2)）。
• CAP_DAC_OVERRIDE
  繞過文件的讀，寫，和執行權限檢查。（DAC 是 "discretionary access control" 的縮寫。）
• CAP_DAC_READ_SEARCH
  • 繞過文件的讀權限檢查和目錄的讀和執行權限檢查；
  • 調用 open_by_handle_at(2)。
• CAP_FOWNER
  • 對于通常要求進程的文件系統 UID 與文件的 UID 匹配的操作，繞過權限檢查 (比如，chmod(2)，utime(2))，除了那些包含在 CAP_DAC_OVERRIDE 和 CAP_DAC_READ_SEARCH 中的操作；
  • 為任意文件設置擴展文件屬性(參考 chattr(1))；
  • 為任意文件設置訪問控制表(ACLs)；
  • 對文件刪除操作忽略目錄的 sticky 位；
  • 在 open(2) 和 fcntl(2) 任意文件時設置 O_NOATIME。
• CAP_FSETID
  當文件修改時不清除 set-user-ID 和 set-group-ID 模式位；為文件 GID 與調用進程的文件系統或補充 GIDs 不匹配的文件設置 set-group-ID 位。
• CAP_IPC_LOCK
  鎖定內存 (mlock(2)，mlockall(2)，mmap(2)，shmctl(2))。
• CAP_IPC_OWNER
  繞過對 System V IPC 對象的操作的權限檢查。
• CAP_KILL
  繞過發送信號 (參考 kill(2)) 時的權限檢查。這包括使用 ioctl(2) KDSIGACCEPT 操作。
• CAP_LEASE（自 Linux 2.4）
  為任意文件建立租約 (參考 fcntl(2))。
• CAP_LINUX_IMMUTABLE
  設置FS_APPEND_FL 和 FS_IMMUTABLE_FL inode 標記 (參考 chattr(1))。
• CAP_MAC_ADMIN（自 Linux 2.6.25）
  覆蓋強制訪問控制 (Mandatory Access Control (MAC)). 為 Smack Linux 安全模塊(Linux Security Module (LSM)) 而實現。
• CAP_MAC_OVERRIDE（自 Linux 2.6.25）
  允許 MAC 配置或狀態改變。為 Smack LSM 而實現。
• CAP_MKNOD（自 Linux 2.4）
  使用 mknod(2) 創建特殊文件。
• CAP_NET_ADMIN
  執行多種網絡有關的操作：
  • 接口配置；
  • IP 防火墻，地址偽裝，和賬單管理；
  • 修改路由表；
  • 為透明代理綁定任何地址；
  • 設置服務類性 (type-of-service (TOS))；
  • 清理驅動統計資料；
  • 設置混雜模式；
  • 啟用組播；
  • 使用 setsockopt(2) 設置下列 socket 選項：SO_DEBUG，SO_MARK，SO_PRIORITY (在0到6范圍之外的優先級)，SO_RCVBUFFORCE，和 SO_SNDBUFFORCE。
• CAP_NET_BIND_SERVICE
  將一個 socket 綁定到一個互聯網域特權端口 (端口號小于 1024)。
• CAP_NET_BROADCAST
  (未使用) 使 socket 發送組播，并監聽組播。
• CAP_NET_RAW
  • 使用 RAW 和 PACKET sockets；
  • 為透明代理綁定任何地址。
• CAP_SETGID
  執行任意的進程 GIDs 和補充 GID 列表管理；當通過 UNIX 域 sockets 傳遞 socket 認證信息時偽造 GID；在一個用戶命名空間 (參考 user_namespaces(7)) 中寫入組 ID 映射。
• CAP_SYS_ADMIN
  • 執行一系列系統管理操作，包括：quotactl(2)，mount(2)，umount(2)，swapon(2)，swapoff(2)，sethostname(2)，和 setdomainname(2)；
  • 執行特權 syslog(2) 操作 (自 Linux 2.6.37 開始，應該使用 CAP_SYSLOG 來允許這一操作)；
  • 執行 VM86_REQUEST_IRQ vm86(2) 命令；
  • 對任意 System V IPC 對象執行 IPC_SET 和 IPC_RMID 操作；
  • 覆蓋 RLIMIT_NPROC 資源限制；
  • 執行 trusted 和 security Extended Attributes (see xattr(7)) 操作；
  • 使用 lookup_dcookie(2)；
  • 使用 ioprio_set(2) 來分配 IOPRIO_CLASS_RT 和 (Linux 2.6.25 之前) IOPRIO_CLASS_IDLE I/O 調度類別；
  • 當通過 UNIX 域 sockets 傳遞 socket 認證信息時偽裝 PID；
  • 在系統調用打開文件 (比如，accept(2)，execve(2)，open(2)，pipe(2)) 時，超出 /proc/sys/fs/file-max，系統范圍內打開文件數的限制；
  • 通過 clone(2) 和 unshare(2) 使用 CLONE_* 標記創建新的命名空間（但是，自從 Linux 3.8 開始，創建命名空間不需要任何權能）；
  • 調用 perf_event_open(2)；
  • 訪問特權 perf 事件信息；
  • 調用 setns(2) (在目標命名空間中需要 CAP_SYS_ADMIN)；
  • 調用 fanotify_init(2)；
  • 調用 bpf(2)；
  • 執行 KEYCTL_CHOWN 和 KEYCTL_SETPERM keyctl(2) 操作；
  • 執行 madvise(2) MADV_HWPOISON 操作；
  • 使用 TIOCSTI ioctl(2) 向一個終端的輸入隊列中插入字符，而不是調用者的控制終端；
  • 使用廢棄的 nfsservctl (2) 系統調用；
  • 使用廢棄的 bdflush (2) 系統調用；
  • 執行各種特權的塊設備 ioctl(2) 操作；
  • 執行各種特權的文件系統 ioctl(2) 操作；
  • 對許多設備驅動執行管理操作。
• CAP_SYS_BOOT
  使用 reboot(2) 和 kexec_load(2)。
• CAP_SYS_CHROOT
  使用 chroot(2)。
• CAP_SYS_MODULE
  加載和卸載內核模塊(參考 init_module(2) 和 delete_module(2))；在 2.6.25 之前的內核中：從系統范圍內的權能邊界集合中丟棄權能。
• CAP_SYS_NICE
  • 觸發進程 nice 值 (nice(2)，setpriority(2)) 和為任意進程改變 nice 值；
  • 為調用進程設置實時調度策略，及為任意進程設置調度策略和優先級 (sched_setscheduler(2)，sched_setparam(2)，shed_setattr(2))；
  • 為任意進程設置 CPU affinity (sched_setaffinity(2))；
  • 為任意進程設置 I/O 調度類別和優先級 (ioprio_set(2))；
  • 對任意進程應用 migrate_pages(2) 并允許進程被遷移到任意節點；
  • 對任意進程應用 move_pages(2)；
  • 在 mbind(2) 和 move_pages(2) 中使用 MPOL_MF_MOVE_ALL 標記。
• CAP_SYS_PACCT
  使用 acct(2)。
• CAP_SYS_PTRACE
  • 使用 ptrace(2) 追蹤任意進程；
  • 對任意進程應用 get_robust_list(2)；
  • 使用 process_vm_readv(2) 和 process_vm_writev(2) 同任意進程的內存傳輸數據；
  • 使用 kcmp(2) 檢查進程。
• CAP_SYS_RAWIO
  • 執行 I/O 端口操作 (iopl(2) 和 ioperm(2))；
  • 訪問 /proc/kcore；
  • 使用 FIBMAP ioctl(2) 操作；
  • 打開設備訪問 x86 模式特有寄存器 (MSRs，參考 msr(4))；
  • 更新 /proc/sys/vm/mmap_min_addr；
  • 在地址低于 /proc/sys/vm/mmap_min_addr 的位置創建內存映射；
  • 在 /proc/bus/pci 中映射文件；
  • 打開 /dev/mem 和 /dev/kmem；
  • 執行各種 SCSI 設備命令；
  • 在 hpsa(4) 和 cciss(4) 設備上執行某一操作；
  • 在其它設備上執行一系列設備特有操作。
• CAP_SYS_RESOURCE
  • 使用 ext2 文件系統上的預留空間；
  • 執行 ioctl(2) 調用控制 ext3 日志；
  • 覆蓋磁盤配額限制；
  • 增加資源限制 (參考 setrlimit(2))；
  • 覆蓋 RLIMIT_NPROC 資源限制；
  • 在終端分配上覆蓋最大的終端數；
  • 覆蓋最大的 keymaps 個數；
  • 允許實時時鐘中斷大于64 hz；
  • 觸發一個 System V 消息隊列的 msg_qbytes 限制超過 /proc/sys/kernel/msgmnb 中的限制 (參考 msgop(2) 和 msgctl(2))；
  • 當使用 F_SETPIPE_SZ fcntl(2) 命令設置一個管道的容量時覆蓋 /proc/sys/fs/pipe-size-max 的限制；
  • 使用 F_SETPIPE_SZ 增加管道的容量超出 /proc/sys/fs/pipe-max-size 指定的限制；
  • 當創建 POSIX 消息隊列 (參考 mq_overview(7)) 時覆蓋 /proc/sys/fs/mqueue/queues_max 的限制；
  • 使用 prctl(2) PR_SET_MM 操作；
  • 設置 /proc/PID/oom_score_adj 為一個小于由一個具有 CAP_SYS_RESOURCE 的進程最近設置的值的值。
• CAP_SYS_TIME
  設置系統時鐘 (settimeofday(2)，stime(2)，adjtimex(2))；設置實時 (硬件) 時鐘。
• CAP_SYS_TTY_CONFIG
  使用 vhangup(2)；對虛擬終端使用各種特權 ioctl(2) 操作。
• CAP_SYSLOG (自 Linux 2.6.37)
  • 執行特權 syslog(2) 操作。參考 syslog(2) 來獲取哪些操作需要特權的信息；
  • 當 /proc/sys/kernel/kptr_restrict 值為 1 時，查看通過 /proc 和其它接口暴露
    的內核地址。(參考 proc(5) 中 kptr_restrict 的討論。)
• CAP_WAKE_ALARM (自 Linux 3.0)
  觸發將喚醒系統的東西 (設置 CLOCK_REALTIME_ALARM 和 CLOCK_BOOTTIME_ALARM 定時器)。

過去和當前的實現

權能的完整實現需要：

對于所有的特權操作，內核必須檢查線程是否在其有效集合中具有要求的權能。

內核必須提供系統調用以允許設置和提取一個線程的權能。

文件系統必須支持為一個可執行文件附接權能，以使文件被執行時進程獲得那些權能。

在內核 2.6.24 之前，只有前兩個要求能夠滿足；自內核 2.6.24 開始，所有三個要求都能滿足。

線程權能集合

每個線程具有三個包含零個或多個上面的權能的權能集合：

• 被允許的 (Permitted)：
  這是線程可以承擔的有效權能的限制性超集。這也是在線程的有效集合中不包含 CAP_SETPCAP 權能時，可以被線程添加進可繼承的集合的權能的限制性超集。

  如果一個線程從它的被允許集合中丟棄了一個權能，則它將永遠無法重新獲取該權能 (除非它 execve(2)s 一個 set-user-ID-root 程序，或一個關聯的文件權能獲取了該權能授權的程序)。

• 可繼承的 (Inheritable)：
  這是跨越一個 execve(2) 保留的權能的集合。當執行任何程序時可繼承的權能保持可繼承，且當執行一個在文件的可繼承集合中設置了對應位的程序時可繼承權能被添加進被允許的集合。

  由于可繼承的權能在以非 root 用戶運行時通常不跨 execve(2) 保留，希望以抬高的權能運行輔助程序的應用應該考慮使用外界的權能，在下面描述。

• 有效地 (Effective)：
  這是內核用來為線程執行權限檢查的權能集合。

• 外界的 (Ambient) (自 Linux 4.3)：
  這是一個為非特權程序的跨 execve(2) 保留的權能集合。外界的權能集合服從不可變性，如果權能既不是被允許的也不是可繼承的，則它也從不可能是外界的。

  外界的權能集合可以直接使用 prctl(2) 修改。如果對應的被允許的或可繼承的權能被降低，外界的權能將自動地降低。

  執行一個由于 set-user-ID 或 set-group-ID 位而修改 UID 或 GID 的程序，或執行一個具有任何文件權能集合的程序將清除外界的集合。在調用 execve(2) 時外界的權能被添加進被允許的集合，并被賦值給有效集合。

A child created via fork(2) inherits copies of its parent's capability sets. See below for a discussion of the treatment of capabilities during execve(2).

Using capset(2), a thread may manipulate its own capability sets (see below).

Since Linux 3.2, the file /proc/sys/kernel/cap_last_cap exposes the numerical value of the highest capability supported by the running kernel; this can be used to determine the highest bit that may be set in a capability set.

文件權能

Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8). The file capability sets are stored in an extended attribute (see setxattr(2)) named security.capability. Writing to this extended attribute requires the CAP_SETFCAP capability. The file capability sets, in conjunction with the capability sets of the thread, determine the capabilities of a thread after an execve(2).

The three file capability sets are:

• Permitted (formerly known as forced):
  These capabilities are automatically permitted to the thread, regardless of the thread's inheritable capabilities.

• Inheritable (formerly known as allowed):
  This set is ANDed with the thread's inheritable set to determine which inheritable capabilities are enabled in the permitted set of the thread after the execve(2).

• Effective:
  This is not a set, but rather just a single bit. If this bit is set, then during an execve(2) all of the new permitted capabilities for the thread are also raised in the effective set. If this bit is not set, then after an execve(2), none of the new permitted capabilities is in the new effective set.

  Enabling the file effective capability bit implies that any file permitted or inheritable capability that causes a thread to acquire the corresponding permitted capability during an execve(2) (see the transformation rules described below) will also acquire that capability in its effective set. Therefore, when assigning capabilities to a file (setcap(8), cap_set_file(3), cap_set_fd(3)), if we specify the effective flag as being enabled for any capability, then the effective flag must also be specified as enabled for all other capabilities for which the corresponding permitted or inheritable flags is enabled.

execve() 期間的權能轉換

During an execve(2), the kernel calculates the new capabilities of the process using the following algorithm:

• 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) [i.e., unchanged]

其中：

• P denotes the value of a thread capability set before the execve(2)

• P' denotes the value of a capability set after the execve(2)

• F denotes a file capability set

• cap_bset is the value of the capability bounding set (described below).

A privileged file is one that has capabilities or has the set-user-ID or set-group-ID bit set.

root 的程序的權能和執行

In order to provide an all-powerful root using capability sets, during an execve(2):

If a set-user-ID-root program is being executed, or the real user ID of the process is 0 (root) then the file inheritable and permitted sets are defined to be all ones (i.e., all capabilities enabled).

If a set-user-ID-root program is being executed, then the file effective bit is defined to be one (enabled).

The upshot of the above rules, combined with the capabilities transformations described above, is that when a process execve(2)s a set-user-ID-root program, or when a process with an effective UID of 0 execve(2)s a program, it gains all capabilities in its permitted and effective capability sets, except those masked out by the capability bounding set. This provides semantics that are the same as those provided by traditional UNIX systems.

權能邊界集合

The capability bounding set is a security mechanism that can be used to limit the capabilities that can be gained during an execve(2). The bounding set is used in the following ways:

• During an execve(2), the capability bounding set is ANDed with the file permitted capability set, and the result of this operation is assigned to the thread's permitted capability set. The capability bounding set thus places a limit on the permitted capabilities that may be granted by an executable file.

• (Since Linux 2.6.25) The capability bounding set acts as a limiting superset for the capabilities that a thread can add to its inheritable set using capset(2). This means that if a capability is not in the bounding set, then a thread can't add this capability to its inheritable set, even if it was in its permitted capabilities, and thereby cannot have this capability preserved in its permitted set when it execve(2)s a file that has the capability in its inheritable set.

Note that the bounding set masks the file permitted capabilities, but not the inherited capabilities. If a thread maintains a capability in its inherited set that is not in its bounding set, then it can still gain that capability in its permitted set by executing a file that has the capability in its inherited set.

Depending on the kernel version, the capability bounding set is either a system-wide attribute, or a per-process attribute.

Linux 2.6.25 之前的權能邊界集合

In kernels before 2.6.25, the capability bounding set is a system-wide attribute that affects all threads on the system. The bounding set is accessible via the file /proc/sys/kernel/cap-bound. (Confusingly, this bit mask parameter is expressed as a signed decimal number in /proc/sys/kernel/capbound.)

Only the init process may set capabilities in the capability bounding set; other than that, the superuser (more precisely: programs with the CAP_SYS_MODULE capability) may only clear capabilities from this set.

On a standard system the capability bounding set always masks out the CAP_SETPCAP capability. To remove this restriction (dangerous!), modify the definition of CAP_INIT_EFF_SET in include/linux/capability.h and rebuild the kernel.

The system-wide capability bounding set feature was added to Linux starting with kernel version 2.2.11.

Linux 2.6.25 之后的權能邊界集合

From Linux 2.6.25, the capability bounding set is a per-thread attribute. (There is no longer a systemwide capability bounding set.)

The bounding set is inherited at fork(2) from the thread's parent, and is preserved across an execve(2).

A thread may remove capabilities from its capability bounding set using the prctl(2) PR_CAPBSET_DROP operation, provided it has the CAP_SETPCAP capability. Once a capability has been dropped from the bounding set, it cannot be restored to that set. A thread can determine if a capability is in its bounding set using the prctl(2) PR_CAPBSET_READ operation.

Removing capabilities from the bounding set is supported only if file capabilities are compiled into the kernel. In kernels before Linux 2.6.33, file capabilities were an optional feature configurable via the CONFIG_SECURITY_FILE_CAPABILITIES option. Since Linux 2.6.33, the configuration option has been removed and file capabilities are always part of the kernel. When file capabilities are compiled into the kernel, the init process (the ancestor of all processes) begins with a full bounding set. If file capabilities are not compiled into the kernel, then init begins with a full bounding set minus CAP_SETPCAP, because this capability has a different meaning when there are no file capabilities.

Removing a capability from the bounding set does not remove it from the thread's inherited set. However it does prevent the capability from being added back into the thread's inherited set in the future.

Effect of user ID changes on capabilities

To preserve the traditional semantics for transitions between 0 and nonzero user IDs, the kernel makes the following changes to a thread's capability sets on changes to the thread's real, effective, saved set, and filesystem user IDs (using setuid(2), setresuid(2), or similar):

If one or more of the real, effective or saved set user IDs was previously 0, and as a result of the UID changes all of these IDs have a nonzero value, then all capabilities are cleared from the permitted and effective capability sets.

If the effective user ID is changed from 0 to nonzero, then all capabilities are cleared from the effective set.

If the effective user ID is changed from nonzero to 0, then the permitted set is copied to the effective set.

If the filesystem user ID is changed from 0 to nonzero (see setfsuid(2)), then the following capabilities are cleared from the effective set: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (since Linux 2.6.30), CAP_MAC_OVERRIDE, and CAP_MKNOD (since Linux 2.6.30). If the filesystem UID is changed from nonzero to 0, then any of these capabilities that are enabled in the permitted set are enabled in the effective set.

If a thread that has a 0 value for one or more of its user IDs wants to prevent its permitted capability set being cleared when it resets all of its user IDs to nonzero values, it can do so using the prctl(2) PR_SET_KEEPCAPS operation or the SECBIT_KEEP_CAPS securebits flag described below.

以編程方式調整權能集合

A thread can retrieve and change its capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets:

If the caller does not have the CAP_SETPCAP capability, the new inheritable set must be a subset of the combination of the existing inheritable and permitted sets.

(Since Linux 2.6.25) The new inheritable set must be a subset of the combination of the existing inheritable set and the capability bounding set.

The new permitted set must be a subset of the existing permitted set (i.e., it is not possible to acquire permitted capabilities that the thread does not currently have).

The new effective set must be a subset of the new permitted set.

securebits 標志：建立一個僅限權能的環境

Starting with kernel 2.6.26, and with a kernel in which file capabilities are enabled, Linux implements a set of per-thread securebits flags that can be used to disable special handling of capabilities for UID 0 (root). These flags are as follows:

• SECBIT_KEEP_CAPS
  Setting this flag allows a thread that has one or more 0 UIDs to retain its capabilities when it switches all of its UIDs to a nonzero value. If this flag is not set, then such a UID switch causes the thread to lose all capabilities. This flag is always cleared on an execve(2). (This flag provides the same functionality as the older prctl(2) PR_SET_KEEPCAPS operation.)

• SECBIT_NO_SETUID_FIXUP
  Setting this flag stops the kernel from adjusting capability sets when the threads's effective and filesystem UIDs are switched between zero and nonzero values. (See the subsection Effect of User ID Changes on Capabilities.)

• SECBIT_NOROOT
  If this bit is set, then the kernel does not grant capabilities when a set-user-ID-root program is executed, or when a process with an effective or real UID of 0 calls execve(2). (See the subsection Capabilities and execution of programs by root.)

• SECBIT_NO_CAP_AMBIENT_RAISE
  Setting this flag disallows raising ambient capabilities via the prctl(2) PR_CAP_AMBIENT_RAISE operation.

Each of the above "base" flags has a companion "locked" flag. Setting any of the "locked" flags is irreversible, and has the effect of preventing further changes to the corresponding "base" flag. The locked flags are: SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED, and SECBIT_NO_CAP_AMBIENT_RAISE.

The securebits flags can be modified and retrieved using the prctl(2) PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. The CAP_SETPCAP capability is required to modify the flags.

The securebits flags are inherited by child processes. During an execve(2), all of the flags are preserved, except SECBIT_KEEP_CAPS which is always cleared.

An application can use the following call to lock itself, and all of its descendants, into an environment where the only way of gaining capabilities is by executing a program with associated file capabilities:

prctl(PR_SET_SECUREBITS,SECBIT_KEEP_CAPS_LOCKED |SECBIT_NO_SETUID_FIXUP |SECBIT_NO_SETUID_FIXUP_LOCKED |SECBIT_NOROOT |SECBIT_NOROOT_LOCKED);

與用戶命名空間交互

For a discussion of the interaction of capabilities and user namespaces, see user_namespaces(7).

標準參考

No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ?http://wt.tuxomania.net/publications/posix.1e/?.

備注

From kernel 2.5.27 to kernel 2.6.26, capabilities were an optional kernel component, and can be enabled/disabled via the CONFIG_SECURITY_CAPABILITIES kernel configuration option.

The /proc/PID/task/TID/status file can be used to view the capability sets of a thread. The /proc/PID/status file shows the capability sets of a process's main thread. Before Linux 3.8, nonexistent capabilities were shown as being enabled (1) in these sets. Since Linux 3.8, all nonexistent capabilities (above CAP_LAST_CAP) are shown as disabled (0).

The libcap package provides a suite of routines for setting and getting capabilities that is more comfortable and less likely to change than the interface provided by capset(2) and capget(2). This package also provides the setcap(8) and getcap(8) programs. It can be found at ?http://www.kernel.org/pub/linux/libs/security/linux-privs?.

Before kernel 2.6.24, and from kernel 2.6.24 to kernel 2.6.32 if file capabilities are not enabled, a thread with the CAP_SETPCAP capability can manipulate the capabilities of threads other than itself. However, this is only theoretically possible, since no thread ever has CAP_SETPCAP in either of these cases:

• In the pre-2.6.25 implementation the system-wide capability bounding set, /proc/sys/kernel/cap-bound, always masks out this capability, and this can not be changed without modifying the kernel source and rebuilding.

• If file capabilities are disabled in the current implementation, then init starts out with this capability removed from its per-process bounding set, and that bounding set is inherited by all other processes created on the system.

另請參閱

capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), credentials(7), user_namespaces(7), pthreads(7), getcap(8), setcap(8)

include/linux/capability.h in the Linux kernel source tree

版本記錄

This page is part of release 4.04 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at http://www.kernel.org/doc/man-pages/.

總結

以上是生活随笔為你收集整理的Linux 权能综述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。