CAP_CLEAR(3)

πŸ“¦
version 2.78 Β· 2 versions
  • 2.78 Β· alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, centos-stream 10, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 2.66 Β· debian bookworm, ubuntu noble
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, centos-stream 10, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ CAP_CLEAR πŸ’– (the Linux Programmer's Manual girlies' edition)

okay so bestie, welcome to the little corner of libcap where we poke at capability data objects πŸŽ€ this is CAP_CLEAR(3) from the Linux Programmer's Manual and it's lowkey one of the most useful pages ever, no cap.


🌸 NAME 🌸

cap_clear, cap_clear_flag, cap_get_flag, cap_set_flag, cap_fill_flag, cap_fill, cap_compare, cap_max_bits β€” capability data object manipulation ✨

it's giving "we're gonna mess with capabilities in working storage" and honestly? iconic.


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <sys/capability.h>

int cap_clear(cap_t cap_p);
int cap_clear_flag(cap_t cap_p, cap_flag_t flag);
int cap_get_flag(cap_t cap_p, cap_value_t cap,
                 cap_flag_t flag, cap_flag_value_t *value_p);
int cap_set_flag(cap_t cap_p, cap_flag_t flag, int ncap,
                 const cap_value_t *caps, cap_flag_value_t value);
int cap_fill_flag(cap_t cap_p, cap_flag_t to,
                  const cap_t ref, cap_flag_t from);
int cap_fill(cap_t cap_p, cap_flag_t to, cap_flag_t from);
int cap_compare(cap_t cap_a, cap_t cap_b);
cap_value_t cap_max_bits();

Link with -lcap.
🌈 friendly reminder: link with -lcap or the linker will simply not know her. periodt.

πŸ’œ DESCRIPTION πŸ’œ

so these functions all work on a capability state held in working storage. a cap_t holds info about the capabilities in each of the three flags β€” Permitted, Inheritable, and Effective. and every single capability in a set can be either clear (disabled, 0) or set (enabled, 1). that's it, that's the vibe check 🌸

πŸ“ the data types, bestie (know them, love them)

  • cap_value_t β€” identifies a capability, such as CAP_CHOWN. yeah, that's the girl.
  • cap_flag_t β€” identifies one of the three flags associated with a capability (i.e., it identifies one of the three capability dimensions πŸ‘‘). valid values for this type are CAP_EFFECTIVE, CAP_INHERITABLE or CAP_PERMITTED.
  • cap_flag_value_t β€” identifies the setting of a particular capability flag (i.e, the value of a capability in a set). valid values for this type are CAP_CLEAR (0) or CAP_SET (1).

🧚 and now the functions, one by one

  • cap_clear() β€” initializes the capability state in working storage identified by cap_p so that all capability flags are cleared. a full reset, a clean slate, main character energy ✨
  • cap_clear_flag() β€” clears all of the capabilities of the specified capability flag, flag. just that one flag, not the whole girl.
  • cap_get_flag() β€” obtains the current value of the capability flag, flag, of the capability, cap, from the capability state identified by cap_p and places it in the location pointed to by value_p. yes bestie it writes through the pointer, that's the whole point πŸ’…
  • cap_set_flag() β€” sets the flag, flag, of each capability in the array caps in the capability state identified by cap_p to value. the argument, ncap, is used to specify the number of capabilities in the array, caps. so like, how many are in the group chat 🫢
  • cap_fill_flag() β€” fills the to flag of one capability set, with the values in the from flag of a reference capability set. copying, but make it cap-flavoured.
  • cap_fill() β€” fills the to flag values by copying all of the from flag values. the glow-up transfer 😌
  • cap_compare() β€” compares two full capability sets and, in the spirit of memcmp(), returns zero if the two capability sets are identical. a positive return value indicates there is a difference between them. the returned value carries further information about the cap_flag_t flag differences. Specifically, the macro CAP_DIFFERS (value, flag) evaluates to non-zero if the returned value differs in its flag components. iykyk πŸ”₯
  • cap_max_bits() β€” returns the number of capability values known to the running kernel. this may differ from libcap's list known at compilation time. Unnamed, at compilation time, capabilites can be referred to numerically and libcap will handle them appropriately. Note, the running kernel wins and it gets to define what "all" capabilities means. she's the boss, fr fr πŸ‘‘

πŸ’€ RETURN VALUE πŸ’€

cap_clear(), cap_clear_flag(), cap_get_flag() cap_set_flag() and cap_compare() return zero on success, and -1 on failure. Other return values for cap_compare() are described above. The function cap_max_bits() returns a numeric value of type cap_value_t that is one larger than the largest actual value known to the running kernel.

On failure, errno is set to EINVAL, indicating that one of the arguments is invalid. so like, check your args bestie, don't be that girl 😭


πŸ‘‘ CONFORMING TO πŸ‘‘

These functions are mostly as per specified in the withdrawn POSIX.1e draft specification. The following are Linux extensions: cap_fill(), cap_fill_flag(), cap_clear_flag(), cap_compare() and cap_max_bits(). yes, withdrawn β€” we still love her though πŸŽ€


🌈 SEE ALSO 🌈

libcap(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capabilities(7)


okay that's the whole page bestie, you ate πŸ’… this one's from 2022-10-16, and it's CAP_CLEAR(3) β€” part of the Linux Programmer's Manual β€” signing off with love and no cap πŸ¦‹βœ¨πŸ’–

πŸ“¦ where this page comes from