1CAPGET(2)                  Linux Programmer's Manual                 CAPGET(2)
2
3
4

NAME

6       capget, capset - set/get capabilities of thread(s)
7

SYNOPSIS

9       #include <linux/capability.h> /* Definition of CAP_* and
10                                        _LINUX_CAPABILITY_* constants */
11       #include <sys/syscall.h>      /* Definition of SYS_* constants */
12       #include <unistd.h>
13
14       int syscall(SYS_capget, cap_user_header_t hdrp,
15                   cap_user_data_t datap);
16       int syscall(SYS_capset, cap_user_header_t hdrp,
17                   const cap_user_data_t datap);
18
19       Note:  glibc provides no wrappers for these system calls, necessitating
20       the use of syscall(2).
21

DESCRIPTION

23       These two system calls are the raw kernel  interface  for  getting  and
24       setting  thread capabilities.  Not only are these system calls specific
25       to Linux, but the kernel API is likely to change and use of these  sys‐
26       tem  calls (in particular the format of the cap_user_*_t types) is sub‐
27       ject to extension with each kernel revision, but old programs will keep
28       working.
29
30       The  portable  interfaces  are  cap_set_proc(3) and cap_get_proc(3); if
31       possible, you should use those interfaces in applications; see NOTES.
32
33   Current details
34       Now that you have been warned, some current kernel details.  The struc‐
35       tures are defined as follows.
36
37           #define _LINUX_CAPABILITY_VERSION_1  0x19980330
38           #define _LINUX_CAPABILITY_U32S_1     1
39
40                   /* V2 added in Linux 2.6.25; deprecated */
41           #define _LINUX_CAPABILITY_VERSION_2  0x20071026
42           #define _LINUX_CAPABILITY_U32S_2     2
43
44                   /* V3 added in Linux 2.6.26 */
45           #define _LINUX_CAPABILITY_VERSION_3  0x20080522
46           #define _LINUX_CAPABILITY_U32S_3     2
47
48           typedef struct __user_cap_header_struct {
49              __u32 version;
50              int pid;
51           } *cap_user_header_t;
52
53           typedef struct __user_cap_data_struct {
54              __u32 effective;
55              __u32 permitted;
56              __u32 inheritable;
57           } *cap_user_data_t;
58
59       The  effective,  permitted, and inheritable fields are bit masks of the
60       capabilities defined in capabilities(7).  Note that  the  CAP_*  values
61       are  bit  indexes  and need to be bit-shifted before ORing into the bit
62       fields.  To define the structures for passing to the system  call,  you
63       have   to   use   the   struct   __user_cap_header_struct   and  struct
64       __user_cap_data_struct names because the typedefs are only pointers.
65
66       Kernels  prior  to  2.6.25  prefer  32-bit  capabilities  with  version
67       _LINUX_CAPABILITY_VERSION_1.   Linux  2.6.25  added  64-bit  capability
68       sets, with version _LINUX_CAPABILITY_VERSION_2.  There was, however, an
69       API  glitch,  and Linux 2.6.26 added _LINUX_CAPABILITY_VERSION_3 to fix
70       the problem.
71
72       Note that 64-bit capabilities use datap[0] and datap[1], whereas 32-bit
73       capabilities use only datap[0].
74
75       On  kernels  that support file capabilities (VFS capabilities support),
76       these system calls behave slightly differently.  This support was added
77       as  an  option in Linux 2.6.24, and became fixed (nonoptional) in Linux
78       2.6.33.
79
80       For capget() calls, one can probe the capabilities of  any  process  by
81       specifying its process ID with the hdrp->pid field value.
82
83       For details on the data, see capabilities(7).
84
85   With VFS capabilities support
86       VFS capabilities employ a file extended attribute (see xattr(7)) to al‐
87       low capabilities to be attached to executables.  This  privilege  model
88       obsoletes kernel support for one process asynchronously setting the ca‐
89       pabilities of another.  That is, on kernels that have VFS  capabilities
90       support, when calling capset(), the only permitted values for hdrp->pid
91       are 0 or, equivalently, the value returned by gettid(2).
92
93   Without VFS capabilities support
94       On older kernels that do not provide VFS capabilities support  capset()
95       can,  if  the  caller has the CAP_SETPCAP capability, be used to change
96       not only the caller's own capabilities, but also  the  capabilities  of
97       other  threads.   The  call  operates on the capabilities of the thread
98       specified by the pid field of hdrp when that is nonzero, or on the  ca‐
99       pabilities  of the calling thread if pid is 0.  If pid refers to a sin‐
100       gle-threaded process, then  pid  can  be  specified  as  a  traditional
101       process ID; operating on a thread of a multithreaded process requires a
102       thread ID of the type returned by gettid(2).   For  capset(),  pid  can
103       also  be:  -1,  meaning  perform  the  change on all threads except the
104       caller and init(1); or a value less than -1, in which case  the  change
105       is applied to all members of the process group whose ID is -pid.
106

RETURN VALUE

108       On  success,  zero is returned.  On error, -1 is returned, and errno is
109       set to indicate the error.
110
111       The calls fail with the error EINVAL, and set the version field of hdrp
112       to  the  kernel preferred value of _LINUX_CAPABILITY_VERSION_?  when an
113       unsupported version value is specified.  In this  way,  one  can  probe
114       what the current preferred capability revision is.
115

ERRORS

117       EFAULT Bad  memory  address.  hdrp must not be NULL.  datap may be NULL
118              only when the user is trying to determine the preferred capabil‐
119              ity version format supported by the kernel.
120
121       EINVAL One of the arguments was invalid.
122
123       EPERM  An attempt was made to add a capability to the permitted set, or
124              to set a capability in the effective set that is not in the per‐
125              mitted set.
126
127       EPERM  An  attempt was made to add a capability to the inheritable set,
128              and either:
129
130              *  that capability was not in the caller's bounding set; or
131
132              *  the capability was not in the caller's permitted set and  the
133                 caller  lacked  the  CAP_SETPCAP  capability in its effective
134                 set.
135
136       EPERM  The caller attempted to use capset() to modify the  capabilities
137              of  a thread other than itself, but lacked sufficient privilege.
138              For kernels supporting VFS capabilities, this is  never  permit‐
139              ted.   For kernels lacking VFS support, the CAP_SETPCAP capabil‐
140              ity is required.  (A bug in kernels  before  2.6.11  meant  that
141              this  error could also occur if a thread without this capability
142              tried to change its own capabilities by specifying the pid field
143              as  a  nonzero value (i.e., the value returned by getpid(2)) in‐
144              stead of 0.)
145
146       ESRCH  No such thread.
147

CONFORMING TO

149       These system calls are Linux-specific.
150

NOTES

152       The portable interface to the capability querying and setting functions
153       is provided by the libcap library and is available here:
154http://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git
155

SEE ALSO

157       clone(2), gettid(2), capabilities(7)
158

COLOPHON

160       This  page  is  part of release 5.13 of the Linux man-pages project.  A
161       description of the project, information about reporting bugs,  and  the
162       latest     version     of     this    page,    can    be    found    at
163       https://www.kernel.org/doc/man-pages/.
164
165
166
167Linux                             2021-03-22                         CAPGET(2)
Impressum