1CAPGET(2) Linux Programmer's Manual CAPGET(2)
2
6 capget, capset - set/get capabilities of thread(s)
7
9 #include <sys/capability.h>
10 int capget(cap_user_header_t hdrp, cap_user_data_t datap);
12 int capset(cap_user_header_t hdrp, const cap_user_data_t datap);
14
16 As of Linux 2.2, the power of the superuser (root) has been partitioned
17 into a set of discrete capabilities. Each thread has a set of effec‐
18 tive capabilities identifying which capabilities (if any) it may cur‐
19 rently exercise. Each thread also has a set of inheritable capabili‐
20 ties that may be passed through an execve(2) call, and a set of permit‐
21 ted capabilities that it can make effective or inheritable.
22 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 The portable interfaces are cap_set_proc(3) and cap_get_proc(3); if
31 possible you should use those interfaces in applications. If you wish
32 to use the Linux extensions in applications, you should use the easier-
33 to-use interfaces capsetp(3) and capgetp(3).
34 Current details
36 Now that you have been warned, some current kernel details. The struc‐
37 tures are defined as follows.
38 #define _LINUX_CAPABILITY_VERSION_1 0x19980330
40 #define _LINUX_CAPABILITY_U32S_1 1
41 #define _LINUX_CAPABILITY_VERSION_2 0x20071026
43 #define _LINUX_CAPABILITY_U32S_2 2
44 typedef struct __user_cap_header_struct {
46 __u32 version;
47 int pid;
48 } *cap_user_header_t;
49 typedef struct __user_cap_data_struct {
51 __u32 effective;
52 __u32 permitted;
53 __u32 inheritable;
54 } *cap_user_data_t;
55 The effective, permitted, and inheritable fields are bit masks of the
57 capabilities defined in capability(7). Note the CAP_* values are bit
58 indexes and need to be bit-shifted before ORing into the bit fields.
59 To define the structures for passing to the system call you have to use
60 the struct __user_cap_header_struct and struct __user_cap_data_struct
61 names because the typedefs are only pointers.
62 Kernels prior to 2.6.25 prefer 32-bit capabilities with version
64 _LINUX_CAPABILITY_VERSION_1, and kernels 2.6.25+ prefer 64-bit capabil‐
65 ities with version _LINUX_CAPABILITY_VERSION_2. Note, 64-bit capabili‐
66 ties use datap[0] and datap[1], whereas 32-bit capabilities use only
67 datap[0].
68 Another change affecting the behavior of these system calls is kernel
70 support for file capabilities (VFS capability support). This support
71 is currently a compile time option (added in kernel 2.6.24).
72 For capget() calls, one can probe the capabilities of any process by
74 specifying its process ID with the hdrp->pid field value.
75 With VFS capability support
77 VFS Capability support creates a file-attribute method for adding capa‐
78 bilities to privileged executables. This privilege model obsoletes
79 kernel support for one process asynchronously setting the capabilities
80 of another. That is, with VFS support, for capset() calls the only
81 permitted values for hdrp->pid are 0 or getpid(2), which are equiva‐
82 lent.
83 Without VFS capability support
85 When the kernel does not support VFS capabilities, capset() calls can
86 operate on the capabilities of the thread specified by the pid field of
87 hdrp when that is nonzero, or on the capabilities of the calling thread
88 if pid is 0. If pid refers to a single-threaded process, then pid can
89 be specified as a traditional process ID; operating on a thread of a
90 multithreaded process requires a thread ID of the type returned by get‐
91 tid(2). For capset(), pid can also be: -1, meaning perform the change
92 on all threads except the caller and init(8); or a value less than -1,
93 in which case the change is applied to all members of the process group
94 whose ID is -pid.
95 For details on the data, see capabilities(7).
97
99 On success, zero is returned. On error, -1 is returned, and errno is
100 set appropriately.
101 The calls will fail with the error EINVAL, and set the version field of
103 hdrp to the kernel preferred value of _LINUX_CAPABILITY_VERSION_? when
104 an unsupported version value is specified. In this way, one can probe
105 what the current preferred capability revision is.
106
108 EFAULT Bad memory address. hdrp must not be NULL. datap may be NULL
109 only when the user is trying to determine the preferred capabil‐
110 ity version format supported by the kernel.
111 EINVAL One of the arguments was invalid.
113 EPERM An attempt was made to add a capability to the Permitted set, or
115 to set a capability in the Effective or Inheritable sets that is
116 not in the Permitted set.
117 EPERM The caller attempted to use capset() to modify the capabilities
119 of a thread other than itself, but lacked sufficient privilege.
120 For kernels supporting VFS capabilities, this is never permit‐
121 ted. For kernels lacking VFS support, the CAP_SETPCAP capabil‐
122 ity is required. (A bug in kernels before 2.6.11 meant that
123 this error could also occur if a thread without this capability
124 tried to change its own capabilities by specifying the pid field
125 as a nonzero value (i.e., the value returned by getpid(2))
126 instead of 0.)
127 ESRCH No such thread.
129
131 These system calls are Linux-specific.
132
134 The portable interface to the capability querying and setting functions
135 is provided by the libcap library and is available here:
136 ⟨http://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git⟩
137
139 clone(2), gettid(2), capabilities(7)
140
142 This page is part of release 3.53 of the Linux man-pages project. A
143 description of the project, and information about reporting bugs, can
144 be found at http://www.kernel.org/doc/man-pages/.
145Linux 2013-03-11 CAPGET(2)