man2/capget.2

   1 .\" written by Andrew Morgan <morgan@kernel.org>
   2 .\" may be distributed as per GPL
   3 .\" Modified by David A. Wheeler <dwheeler@ida.org>
   4 .\" Modified 2004-05-27, mtk
   5 .\" Modified 2004-06-21, aeb
   6 .\" Modified 2008-04-28, morgan of kernel.org
   7 .\"     Update in line with addition of file capabilities and
   8 .\"     64-bit capability sets in kernel 2.6.2[45].
   9 .\" Modified 2009-01-26, andi kleen
  10 .\"
  11 .TH CAPGET 2 2010-09-20 "Linux" "Linux Programmer's Manual"
  12 .SH NAME
  13 capget, capset \- set/get capabilities of thread(s)
  14 .SH SYNOPSIS
  15 .B #include <sys/capability.h>
  16 .sp
  17 .BI "int capget(cap_user_header_t " hdrp ", cap_user_data_t " datap );
  18 .sp
  19 .BI "int capset(cap_user_header_t " hdrp ", const cap_user_data_t " datap );
  20 .SH DESCRIPTION
  21 As of Linux 2.2,
  22 the power of the superuser (root) has been partitioned into
  23 a set of discrete capabilities.
  24 Each thread has a set of effective capabilities identifying
  25 which capabilities (if any) it may currently exercise.
  26 Each thread also has a set of inheritable capabilities that may be
  27 passed through an
  28 .BR execve (2)
  29 call, and a set of permitted capabilities
  30 that it can make effective or inheritable.
  31 .PP
  32 These two functions are the raw kernel interface for getting and
  33 setting thread capabilities.
  34 Not only are these system calls specific to Linux,
  35 but the kernel API is likely to change and use of
  36 these functions (in particular the format of the
  37 .I cap_user_*_t
  38 types) is subject to extension with each kernel revision,
  39 but old programs will keep working.
  40 .sp
  41 The portable interfaces are
  42 .BR cap_set_proc (3)
  43 and
  44 .BR cap_get_proc (3);
  45 if possible you should use those interfaces in applications.
  46 If you wish to use the Linux extensions in applications, you should
  47 use the easier-to-use interfaces
  48 .BR capsetp (3)
  49 and
  50 .BR capgetp (3).
  51 .SS "Current details"
  52 Now that you have been warned, some current kernel details.
  53 The structures are defined as follows.
  54 .sp
  55 .nf
  56 .in +4n
  57 #define _LINUX_CAPABILITY_VERSION_1  0x19980330
  58 #define _LINUX_CAPABILITY_U32S_1     1
  59
  60 #define _LINUX_CAPABILITY_VERSION_2  0x20071026
  61 #define _LINUX_CAPABILITY_U32S_2     2
  62
  63 typedef struct __user_cap_header_struct {
  64    __u32 version;
  65    int pid;
  66 } *cap_user_header_t;
  67
  68 typedef struct __user_cap_data_struct {
  69    __u32 effective;
  70    __u32 permitted;
  71    __u32 inheritable;
  72 } *cap_user_data_t;
  73 .fi
  74 .in -4n
  75 .sp
  76 .I effective, permitted, inheritable
  77 are bitmasks of the capabilities defined in
  78 .I capability(7).
  79 Note the
  80 .I CAP_*
  81 values are bit indexes and need to be bit-shifted before ORing into
  82 the bit fields.
  83 To define the structures for passing to the system call you have to use the
  84 .I struct __user_cap_header_struct
  85 and
  86 .I struct __user_cap_data_struct
  87 names because the typedefs are only pointers.
  88
  89 Kernels prior to 2.6.25 prefer
  90 32-bit capabilities with version
  91 .BR _LINUX_CAPABILITY_VERSION_1 ,
  92 and kernels 2.6.25+ prefer 64-bit capabilities with version
  93 .BR _LINUX_CAPABILITY_VERSION_2 .
  94 Note, 64-bit capabilities use
  95 .IR datap [0]
  96 and
  97 .IR datap [1],
  98 whereas 32-bit capabilities only use
  99 .IR datap [0].
 100 .sp
 101 Another change affecting the behavior of these system calls is kernel
 102 support for file capabilities (VFS capability support).
 103 This support is currently a compile time option (added in kernel 2.6.24).
 104 .sp
 105 For
 106 .BR capget ()
 107 calls, one can probe the capabilities of any process by specifying its
 108 process ID with the
 109 .I hdrp->pid
 110 field value.
 111 .SS With VFS Capability Support
 112 VFS Capability support creates a file-attribute method for adding
 113 capabilities to privileged executables.
 114 This privilege model obsoletes kernel support for one process
 115 asynchronously setting the capabilities of another.
 116 That is, with VFS support, for
 117 .BR capset ()
 118 calls the only permitted values for
 119 .I hdrp->pid
 120 are 0 or
 121 .BR getpid (2),
 122 which are equivalent.
 123 .SS Without VFS Capability Support
 124 When the kernel does not support VFS capabilities,
 125 .BR capset ()
 126 calls can operate on the capabilities of the thread specified by the
 127 .I pid
 128 field of
 129 .I hdrp
 130 when that is nonzero, or on the capabilities of the calling thread if
 131 .I pid
 132 is 0.
 133 If
 134 .I pid
 135 refers to a single-threaded process, then
 136 .I pid
 137 can be specified as a traditional process ID;
 138 operating on a thread of a multithreaded process requires a thread ID
 139 of the type returned by
 140 .BR gettid (2).
 141 For
 142 .BR capset (),
 143 .I pid
 144 can also be: \-1, meaning perform the change on all threads except the
 145 caller and
 146 .BR init (8);
 147 or a value less than \-1, in which case the change is applied
 148 to all members of the process group whose ID is \-\fIpid\fP.
 149
 150 For details on the data, see
 151 .BR capabilities (7).
 152 .SH "RETURN VALUE"
 153 On success, zero is returned.
 154 On error, \-1 is returned, and
 155 .I errno
 156 is set appropriately.
 157
 158 The calls will fail with the error
 159 .BR EINVAL ,
 160 and set the
 161 .I version
 162 field of
 163 .I hdrp
 164 to the kernel preferred value of
 165 .B _LINUX_CAPABILITY_VERSION_?
 166 when an unsupported
 167 .I version
 168 value is specified.
 169 In this way, one can probe what the current
 170 preferred capability revision is.
 171 .SH ERRORS
 172 .TP
 173 .B EFAULT
 174 Bad memory address.
 175 .I hdrp
 176 must not be NULL.
 177 .I datap
 178 may only be NULL when the user is trying to determine the preferred
 179 capability version format supported by the kernel.
 180 .TP
 181 .B EINVAL
 182 One of the arguments was invalid.
 183 .TP
 184 .B EPERM
 185 An attempt was made to add a capability to the Permitted set, or to set
 186 a capability in the Effective or Inheritable sets that is not in the
 187 Permitted set.
 188 .TP
 189 .B EPERM
 190 The caller attempted to use
 191 .BR capset ()
 192 to modify the capabilities of a thread other than itself,
 193 but lacked sufficient privilege.
 194 For kernels supporting VFS
 195 capabilities, this is never permitted.
 196 For kernels lacking VFS
 197 support, the
 198 .B CAP_SETPCAP
 199 capability is required.
 200 (A bug in kernels before 2.6.11 meant that this error could also
 201 occur if a thread without this capability tried to change its
 202 own capabilities by specifying the
 203 .I pid
 204 field as a nonzero value (i.e., the value returned by
 205 .BR getpid (2))
 206 instead of 0.)
 207 .TP
 208 .B ESRCH
 209 No such thread.
 210 .SH "CONFORMING TO"
 211 These system calls are Linux-specific.
 212 .SH NOTES
 213 The portable interface to the capability querying and setting
 214 functions is provided by the
 215 .I libcap
 216 library and is available here:
 217 .br
 218 http://www.kernel.org/pub/linux/libs/security/linux-privs
 219 .SH "SEE ALSO"
 220 .BR clone (2),
 221 .BR gettid (2),
 222 .BR capabilities (7)