Return to Answer

How capabilities work in Linux is documented in man 7 capabilities.

Process' capabilities in the effective set are against which permission checks are done. File capabilities are used during execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to process' inherited set and affects how capabilities are calculated during execv. Capabilities can only be dropped from bounding set, not added.

Permissions checks for process are checked against process' effective set. Process can raise its capabilities from permitted to effective set (using capget and capset syscalls, recommended API is respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during execv syscall. During execv new effective and permitted sets are calculated and inherited set and bounding set stay unchanged. The algorithm is described in capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

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

Where P is old capability set, P' is capability set after execv and F is file capability set.

If a capability is in both process' inheritable set and file's inheritable set (intersection/logical AND) it is added to permitted set. File permitted set is added (union/logical OR) to it (if it is within bounding set).

If effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to inherited and permitted sets and effective bit is set. When your binary is executed, the process will have those capabilities in effective and permitted sets if they are not limited by a bounding set.

_{[1] For fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics how capabilities are set in effective and permitted sets.}

The way capabilities work in Linux is documented in man 7 capabilities.

Processes' capabilities in the effective set are against which permission checks are done. File capabilities are used during an execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to a process' inherited set and affects how capabilities are calculated during a call to execv. Capabilities can only be dropped from the bounding set, not added.

Permissions checks for a process are checked against the process' effective set. A process can raise its capabilities from the permitted to the effective set (using capget and capset syscalls, the recommended APIs are respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during an execv syscall. During execv, new effective and permitted sets are calculated and the inherited and bounding sets stay unchanged. The algorithm is described in the capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

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

Where P is the old capability set, P' is the capability set after execv and F is the file capability set.

If a capability is in both processes' inheritable set and the file's inheritable set (intersection/logical AND), it is added to the permitted set. The file's permitted set is added (union/logical OR) to it (if it is within the bounding set).

If the effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to the inherited and permitted sets and the effective bit is set. When your binary is executed, the process will have those capabilities in the effective and permitted sets if they are not limited by a bounding set.

_{[1] For the fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics for how capabilities are set in the effective and permitted sets.}

How capabilities work in Linux is documented in man 7 capabilities.

Process' capabilities in the effective set are against which permission checks are done. File capabilities are used during execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to process' inherited set and affects how capabilities are calculated during execv.

Permissions checks for process are checked against process' effective set. Process can raise its capabilities from permitted to effective set (using capget and capset syscalls, recommended API is respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during execv syscall. During execv new effective and permitted sets are calculated and inherited set and bounding set stay unchanged. The algorithm is described in capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

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

Where P is old capability set, P' is capability set after execv and F is file capability set.

If a capability is in both process' inheritable set and file's inheritable set (intersection/logical AND) it is added to permitted set. File permitted set is added (union/logical OR) to it (if it is within bounding set).

If effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to inherited and permitted sets and effective bit is set. When your binary is executed, the process will have those capabilities in effective and permitted sets if they are not limited by a bounding set.

_{[1] For fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics how capabilities are set in effective and permitted sets.}

How capabilities work in Linux is documented in man 7 capabilities.

Process' capabilities in the effective set are against which permission checks are done. File capabilities are used during execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to process' inherited set and affects how capabilities are calculated during execv. Capabilities can only be dropped from bounding set, not added.

Permissions checks for process are checked against process' effective set. Process can raise its capabilities from permitted to effective set (using capget and capset syscalls, recommended API is respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during execv syscall. During execv new effective and permitted sets are calculated and inherited set and bounding set stay unchanged. The algorithm is described in capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

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

Where P is old capability set, P' is capability set after execv and F is file capability set.

If a capability is in both process' inheritable set and file's inheritable set (intersection/logical AND) it is added to permitted set. File permitted set is added (union/logical OR) to it (if it is within bounding set).

If effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to inherited and permitted sets and effective bit is set. When your binary is executed, the process will have those capabilities in effective and permitted sets if they are not limited by a bounding set.

_{[1] For fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics how capabilities are set in effective and permitted sets.}

How capabilities work in Linux is documented in man 7 capabilities.

Process' capabilities in the effective set are against which permission checks are done. File capabilities are used during execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to process' inherited set and affects how capabilities are calculated during execv.

Permissions checks for process are checked against process' effective set. Process can raise its capabilities from permitted to effective set (using capget and capset syscalls, recommended API is respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during execv syscall. During execv new effective and permitted sets are calculated and inherited set and bounding set stay unchanged. The algorithm is described in capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

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

Where P is old capability set, P' is capability set after execv and F is file capability set.

If a capability is in both process' inheritable set and file's inheritable set (intersection/logical AND) it is added to permitted set. File permitted set is added (union/logical OR) to it (if it is within bounding set).

If effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to inherited and permitted sets and effective bit is set. When your binary is executed, it will have those capabilities in effective and permitted sets if they are not limited by a bounding set.

_{[1] For fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics how capabilities are set in effective and permitted sets.}

How capabilities work in Linux is documented in man 7 capabilities.

Process' capabilities in the effective set are against which permission checks are done. File capabilities are used during execv call (which happens when you want to run another program¹) to calculate the new capability sets for the process.

Files have two sets for capabilities, permitted and inheritable and effective bit.

Processes have three capability sets: effective, permitted and inheritable. There is also a bounding set, which limits which capabilities may be added later to process' inherited set and affects how capabilities are calculated during execv.

Permissions checks for process are checked against process' effective set. Process can raise its capabilities from permitted to effective set (using capget and capset syscalls, recommended API is respectively cap_get_proc and cap_set_proc).

Inheritable and bounding sets and file capabilities come into play during execv syscall. During execv new effective and permitted sets are calculated and inherited set and bounding set stay unchanged. The algorithm is described in capabilities man page:

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

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

Where P is old capability set, P' is capability set after execv and F is file capability set.

If a capability is in both process' inheritable set and file's inheritable set (intersection/logical AND) it is added to permitted set. File permitted set is added (union/logical OR) to it (if it is within bounding set).

If effective bit in file capabilities is set, all permitted capabilities are raised to effective after execv.

Capabilities in kernel are actually set for threads, but regarding file capabilities this distinction is usually relevant only if the process alters its own capabilities.

In your example capabilities cap_net_raw , cap_net_admin and cap_dac_override are added to inherited and permitted sets and effective bit is set. When your binary is executed, the process will have those capabilities in effective and permitted sets if they are not limited by a bounding set.

_{[1] For fork syscall, all the capabilities and the bounding set are copied from parent process. Changes in uid also have their own semantics how capabilities are set in effective and permitted sets.}