dwww Home | Manual pages | Find package

CAP_IAB(3)                 Linux Programmer's Manual                CAP_IAB(3)

NAME
       #include <sys/capability.h>

       cap_iab_t cap_iab_init(void);

       cap_iab_t cap_iab_dup(cap_iab_t iab);

       cap_iab_t cap_iab_get_proc(void);

       cap_iab_t cap_iab_get_pid(pid_t pid);

       int cap_iab_set_proc(cap_iab_t iab);

       char *cap_iab_to_text(cap_iab_t iab);

       cap_iab_t cap_iab_from_text(const char *text);

       cap_flag_value_t cap_iab_get_vector(cap_iab_t iab, cap_iab_vector_t vec,
           cap_value_t val);

       int cap_iab_compare(cap_iab_t a, cap_iab_t b);

       int cap_iab_set_vector(cap_iab_t iab, cap_iab_vector_t vec, cap_value_t val,
           cap_flag_value_t enable);

       int cap_iab_fill(cap_iab_t iab, cap_iab_vector_t vec,
           cap_t set, cap_flag_t flag);

       Link with -lcap.

DESCRIPTION
       The functions defined in this man page concern the three naively inher-
       itable process capability vectors: Inh, Amb and Bound. This IAB 3-tuple
       of capability vectors, captured in type cap_iab_t combine to pass capa-
       bilities from one process to another through  execve(2)  system  calls.
       The  convolution rules using the IAB tuple are a fail over set of rules
       when the executed file has no configured file-capabilities.

       There are some constraints enforced by the kernel with respect  to  the
       three  components  of an IAB tuple and the Permitted process capability
       flag. They are: the Inh vector is entirely equal to the process Inheri-
       table  flag  at  all  times; the Amb vector contains no more capability
       values than the intersection of the Inh vector and the  Permitted  flag
       for  the process; and the Bound (or blocked) vector is the twos-comple-
       ment of the process bounding vector.

       In some environments, it is considered desirable to naively inherit ca-
       pabilities. That is pass capabilities, independent of the status of the
       executed binary, from parent to child through exec* system  calls.  The
       surviving  capabilities  become  the  Permitted  flag for the post-exec
       process. This method of  inheritance  differs  significantly  from  the
       handshake inheritance between a pre-exec* process and a file-capability
       bestowed executable of the traditional (POSIX.1e) capability mechanism.

       The convolution rules for IAB  style  inheritance  are:  I'=I;  A'=A&I;
       P'=A&I&P.  Where P etc are the pre-exec values and P' etc are the post-
       exec values.

       With an understanding of these convolution rules, we  can  explain  how
       libcap(3) support for the IAB tuple is managed: the IAB API.

       cap_iab_init()  returns  an  empty IAB value. That is a mostly-harmless
       tuple. It will not block any Permitted file capabilities through  exec,
       but  it won't bestow any either. The returned cap_iab_t should be freed
       with cap_free(3).

       cap_iab_dup() returns a copy of the specified IAB value.  The  returned
       cap_iab_t should be freed with cap_free(3).

       cap_iab_get_proc()  returns  a  copy  of  the IAB value for the current
       process.  The returned cap_iab_t should be freed with cap_free(3).

       cap_iab_get_pid() returns a copy of the IAB  value  for  the  specified
       process.  The returned cap_iab_t should be freed with cap_free(3).

       cap_iab_set_proc() can be used to set the IAB value carried by the cur-
       rent process. Such a setting will fail if the process is insufficiently
       capable.  The  process  requires CAP_SETPCAP raised in the E flag and a
       superset of P and I values over those in the A vectors.

       cap_iab_to_text() will convert an IAB tuple to a canonical text  repre-
       sentation. The representation is slightly redundant but libcap will try
       to generate as short a representation as it is able.

       cap_iab_from_text() generates an IAB tuple from a text  string  (likely
       generated  by  the previous function). The returned IAB tuple should be
       freed with cap_free(3).

       The text format accepted by cap_iab_from_text() is  a  comma  separated
       list  of  capability values. Each capability is prefixed by nothing (or
       %) (Inh); ! (Bound, but think Blocked); ^ (Amb). Or,  some  combination
       thereof.  Since the Amb vector is constrained to be no greater than the
       Inh vector, ^ is equivalent to %^. Further, unless B is non-zero, % can
       be omitted. The following are legal text representations: "!%cap_chown"
       (Bound but Inh),  "!cap_chown,^cap_chown"  (Bound,  Inh+Amb).  "cap_se-
       tuid,!cap_chown" (Inh, Bound). As noted above, this text representation
       is the syntax for the pam_cap.so config file.

       cap_iab_get_vector() can be used to determine the  specific  capability
       value of an IAB vector.

       cap_iab_compare() can be used to compare two cap_iab_t tuples. When the
       return value is non-zero,  the  macro  CAP_IAB_DIFFERS(status,  vector)
       evaluates to non-zero if the returned status differs in its vector com-
       ponents.

       cap_iab_set_vector() can be used to set a specific vector value to  the
       enable setting.

       cap_iab_fill()  can  be  used to wholesale copy a cap_t flag value into
       the vec vector of the IAB tuple. Copying into Amb in this way  may  im-
       plicitly  raise Inh values in the IAB tuple. Similarly copying into the
       Inh vector may implicitly lower Amb values that are not present in  the
       resulting Inh vector.

ERRORS
       The  functions  returning  cap_iab_t  values or allocated memory in the
       form of a string return NULL on error.

       Integer return values are -1 on error and 0 on success.

       In the case of error consult errno.

NOTES
       Unlike the traditional cap_t capability set, the IAB tuple,  taken  to-
       gether,  is incompatible with filesystem capabilities created via tools
       like setcap(8).  That is, the Amb vector of the IAB tuple  is  rendered
       moot when an executable with a file capability is executed.

       Further,  there  are libcap cap_mode(3)s that render the Amb vector and
       its method of process inheritance disabled.

HISTORY
       The IAB format for inheritable variants of capabilities was  first  de-
       veloped as the configuration syntax for the pam_cap.so Linux-PAM module
       in libcap-2.29. It was introduced to extend the simple comma  separated
       list  of  process Inheritable capabilities, that the module could besow
       on an authenticated process tree, to include  enforced  limits  on  the
       Bounding  vector and introduce support for the Amibient vector of capa-
       bility bits.

       While the Inheritable and Bounding  vectors  were  anticipated  by  the
       POSIX.1e  draft  that  introduced capabilities, the Ambient vector is a
       Linux invention, and incompatible with  the  POSIX.1e  file  capability
       model.  As  such, it was felt that trying to meld together all of the 5
       capability vectors into one text representation was not going to  work.
       Instead  the  pam_cap.so config syntax was generalized into a whole set
       of libcap functions for bundling together all three naively inheritable
       capabilities:  the  IAB  tuple.  The  support  for this debuted in lib-
       cap-2.33.

REPORTING BUGS
       Please report bugs via:

       https://bugzilla.kernel.org/buglist.cgi?component=lib-
       cap&list_id=1090757

SEE ALSO
       libcap(3), cap_launch(3), cap_init(3), capabilities(7) and errno(3).

                                  2021-11-17                        CAP_IAB(3)

Generated by dwww version 1.15 on Wed Jun 26 18:12:00 CEST 2024.