request_key(2)

1REQUEST_KEY(2)            Linux Key Management Calls            REQUEST_KEY(2)
2
3
4

NAME

6       request_key - request a key from the kernel's key management facility
7

SYNOPSIS

9       #include <sys/types.h>
10       #include <keyutils.h>
11
12       key_serial_t request_key(const char *type, const char *description,
13                                const char *callout_info,
14                                key_serial_t dest_keyring);
15
16       No glibc wrapper is provided for this system call; see NOTES.
17

DESCRIPTION

19       request_key()  attempts to find a key of the given type with a descrip‐
20       tion (name) that matches the specified  description.   If  such  a  key
21       could  not be found, then the key is optionally created.  If the key is
22       found or created, request_key() attaches it to the keyring whose ID  is
23       specified in dest_keyring and returns the key's serial number.
24
25       request_key()  first  recursively searches for a matching key in all of
26       the keyrings  attached  to  the  calling  process.   The  keyrings  are
27       searched   in  the  order:  thread-specific  keyring,  process-specific
28       keyring, and then session keyring.
29
30       If request_key() is called from a program invoked by  request_key()  on
31       behalf  of  some  other process to generate a key, then the keyrings of
32       that other process will be searched next, using  that  other  process's
33       user  ID,  group  ID,  supplementary group IDs, and security context to
34       determine access.
35
36       The search of the keyring tree  is  breadth-first:  the  keys  in  each
37       keyring  searched are checked for a match before any child keyrings are
38       recursed into.  Only keys for which the caller has search permission be
39       found, and only keyrings for which the caller has search permission may
40       be searched.
41
42       If the key is not found and callout is NULL, then the call  fails  with
43       the error ENOKEY.
44
45       If  the  key  is  not  found  and  callout is not NULL, then the kernel
46       attempts to invoke a user-space program to instantiate  the  key.   The
47       details are given below.
48
49       The dest_keyring serial number may be that of a valid keyring for which
50       the caller has write permission, or it may be one of the following spe‐
51       cial keyring IDs:
52
53       KEY_SPEC_THREAD_KEYRING
54              This specifies the caller's thread-specific keyring (see thread-
55              keyring(7)).
56
57       KEY_SPEC_PROCESS_KEYRING
58              This  specifies  the  caller's  process-specific  keyring   (see
59              process-keyring(7)).
60
61       KEY_SPEC_SESSION_KEYRING
62              This  specifies  the caller's session-specific keyring (see ses‐
63              sion-keyring(7)).
64
65       KEY_SPEC_USER_KEYRING
66              This specifies the  caller's  UID-specific  keyring  (see  user-
67              keyring(7)).
68
69       KEY_SPEC_USER_SESSION_KEYRING
70              This  specifies  the caller's UID-session keyring (see user-ses‐
71              sion-keyring(7)).
72
73       When the dest_keyring is specified as 0 and  no  key  construction  has
74       been performed, then no additional linking is done.
75
76       Otherwise,  if  dest_keyring is 0 and a new key is constructed, the new
77       key will be linked to the "default" keyring.  More precisely, when  the
78       kernel  tries  to  determine to which keyring the newly constructed key
79       should be linked, it tries the following keyrings, beginning  with  the
80       keyring  set  via the keyctl(2) KEYCTL_SET_REQKEY_KEYRING operation and
81       continuing in the order shown below until it finds  the  first  keyring
82       that exists:
83
84       ·  The   requestor  keyring  (KEY_REQKEY_DEFL_REQUESTOR_KEYRING,  since
85          Linux 2.6.29).
86
87       ·  The  thread-specific  keyring  (KEY_REQKEY_DEFL_THREAD_KEYRING;  see
88          thread-keyring(7)).
89
90       ·  The  process-specific  keyring (KEY_REQKEY_DEFL_PROCESS_KEYRING; see
91          process-keyring(7)).
92
93       ·  The session-specific keyring  (KEY_REQKEY_DEFL_SESSION_KEYRING;  see
94          session-keyring(7)).
95
96       ·  The     session     keyring    for    the    process's    user    ID
97          (KEY_REQKEY_DEFL_USER_SESSION_KEYRING; see user-session-keyring(7)).
98          This keyring is expected to always exist.
99
100       ·  The  UID-specific  keyring  (KEY_REQKEY_DEFL_USER_KEYRING; see user-
101          keyring(7)).  This keyring is also expected to always exist.
102
103       If  the   keyctl(2)   KEYCTL_SET_REQKEY_KEYRING   operation   specifies
104       KEY_REQKEY_DEFL_DEFAULT  (or  no KEYCTL_SET_REQKEY_KEYRING operation is
105       performed), then the kernel looks  for  a  keyring  starting  from  the
106       beginning of the list.
107
108   Requesting user-space instantiation of a key
109       If  the  kernel  cannot  find  a key matching type and description, and
110       callout is not NULL, then the kernel attempts to  invoke  a  user-space
111       program  to  instantiate a key with the given type and description.  In
112       this case, the following steps are performed:
113
114       a)  The kernel creates an uninstantiated key,  U,  with  the  requested
115           type and description.
116
117       b)  The  kernel creates an authorization key, V, that refers to the key
118           U and records the facts that the caller of request_key() is:
119
120           (1) the context in which the  key  U  should  be  instantiated  and
121               secured, and
122
123           (2) the  context  from  which associated key requests may be satis‐
124               fied.
125
126           The authorization key is constructed as follows:
127
128           *  The key type is ".request_key_auth".
129
130           *  The key's UID and GID are the same as the corresponding filesys‐
131              tem IDs of the requesting process.
132
133           *  The  key  grants  view,  read, and search permissions to the key
134              possessor as well as view permission for the key user.
135
136           *  The description (name) of the key is the hexadecimal string rep‐
137              resenting  the  ID  of the key that is to be instantiated in the
138              requesting program.
139
140           *  The payload of the key is taken from the data specified in call‐
141              out_info.
142
143           *  Internally,  the kernel also records the PID of the process that
144              called request_key().
145
146       c)  The kernel creates a process that  executes  a  user-space  service
147           such  as  request-key(8) with a new session keyring that contains a
148           link to the authorization key, V.
149
150           This program is supplied with the following command-line arguments:
151
152           [0] The string "/sbin/request-key".
153
154           [1] The string "create" (indicating that a key is to be created).
155
156           [2] The ID of the key that is to be instantiated.
157
158           [3] The filesystem UID of the caller of request_key().
159
160           [4] The filesystem GID of the caller of request_key().
161
162           [5] The ID of the thread keyring of the  caller  of  request_key().
163               This may be zero if that keyring hasn't been created.
164
165           [6] The  ID  of the process keyring of the caller of request_key().
166               This may be zero if that keyring hasn't been created.
167
168           [7] The ID of the session keyring of the caller of request_key().
169
170           Note: each of the command-line  arguments  that  is  a  key  ID  is
171           encoded  in  decimal (unlike the key IDs shown in /proc/keys, which
172           are shown as hexadecimal values).
173
174       d)  The program spawned in the previous step:
175
176           *  Assumes the  authority  to  instantiate  the  key  U  using  the
177              keyctl(2)  KEYCTL_ASSUME_AUTHORITY  operation (typically via the
178              keyctl_assume_authority(3) function).
179
180           *  Obtains the callout data from the payload of  the  authorization
181              key  V (using the keyctl(2) KEYCTL_READ operation (or, more com‐
182              monly, the keyctl_read(3) function)  with  a  key  ID  value  of
183              KEY_SPEC_REQKEY_AUTH_KEY).
184
185           *  Instantiates  the  key  (or  execs another program that performs
186              that task), specifying  the  payload  and  destination  keyring.
187              (The destination keyring that the requestor specified when call‐
188              ing request_key() can be  accessed  using  the  special  key  ID
189              KEY_SPEC_REQUESTOR_KEYRING.)   Instantiation  is performed using
190              the keyctl(2) KEYCTL_INSTANTIATE operation (or,  more  commonly,
191              the   keyctl_instantiate(3)   function).   At  this  point,  the
192              request_key() call completes, and  the  requesting  program  can
193              continue execution.
194
195       If  these steps are unsuccessful, then an ENOKEY error will be returned
196       to the caller of request_key() and a temporary, negatively instantiated
197       key  will  be installed in the keyring specified by dest_keyring.  This
198       will expire after a few seconds, but will  cause  subsequent  calls  to
199       request_key()  to  fail  until it does.  The purpose of this negatively
200       instantiated key is to prevent (possibly  different)  processes  making
201       repeated requests (that require expensive request-key(8) upcalls) for a
202       key that can't (at the moment) be positively instantiated.
203
204       Once  the  key   has   been   instantiated,   the   authorization   key
205       (KEY_SPEC_REQKEY_AUTH_KEY)  is  revoked,  and  the  destination keyring
206       (KEY_SPEC_REQUESTOR_KEYRING) is no longer accessible from the  request-
207       key(8) program.
208
209       If  a key is created, then—regardless of whether it is a valid key or a
210       negatively instantiated key—it will displace any  other  key  with  the
211       same type and description from the keyring specified in dest_keyring.
212

RETURN VALUE

214       On success, request_key() returns the serial number of the key it found
215       or caused to be created.  On error, -1 is returned and errno is set  to
216       indicate the cause of the error.
217

ERRORS

219       EACCES The keyring wasn't available for modification by the user.
220
221       EDQUOT The  key  quota for this user would be exceeded by creating this
222              key or linking it to the keyring.
223
224       EFAULT One of type, description, or  callout_info  points  outside  the
225              process's accessible address space.
226
227       EINTR  The request was interrupted by a signal; see signal(7).
228
229       EINVAL The  size  of  the  string (including the terminating null byte)
230              specified in type or description exceeded the  limit  (32  bytes
231              and 4096 bytes respectively).
232
233       EINVAL The  size  of  the  string (including the terminating null byte)
234              specified in callout_info exceeded the system page size.
235
236       EKEYEXPIRED
237              An expired key was found, but no replacement could be obtained.
238
239       EKEYREJECTED
240              The attempt to generate a new key was rejected.
241
242       EKEYREVOKED
243              A revoked key was found, but no replacement could be obtained.
244
245       ENOKEY No matching key was found.
246
247       ENOMEM Insufficient memory to create a key.
248
249       EPERM  The type argument started with a period ('.').
250

VERSIONS

252       This system call first  appeared  in  Linux  2.6.10.   The  ability  to
253       instantiate keys upon request was added in Linux 2.6.13.
254

CONFORMING TO

256       This system call is a nonstandard Linux extension.
257

NOTES

259       No  wrapper  for  this  system call is provided in glibc.  A wrapper is
260       provided in the libkeyutils package.  When  employing  the  wrapper  in
261       that library, link with -lkeyutils.
262

EXAMPLE

264       The  program  below  demonstrates  the use of request_key().  The type,
265       description, and callout_info arguments for the system call  are  taken
266       from the values supplied in the command-line arguments.  The call spec‐
267       ifies the session keyring as the target keyring.
268
269       In order to demonstrate this program, we first create a suitable  entry
270       in the file /etc/request-key.conf.
271
272           $ sudo sh
273           # echo 'create user mtk:* *   /bin/keyctl instantiate %k %c %S' \
274                     > /etc/request-key.conf
275           # exit
276
277       This  entry specifies that when a new "user" key with the prefix "mtk:"
278       must be instantiated, that task should be performed via  the  keyctl(1)
279       command's instantiate operation.  The arguments supplied to the instan‐
280       tiate operation are: the ID of the uninstantiated key (%k); the callout
281       data  supplied  to the request_key() call (%c); and the session keyring
282       (%S) of  the  requestor  (i.e.,  the  caller  of  request_key()).   See
283       request-key.conf(5) for details of these % specifiers.
284
285       Then  we run the program and check the contents of /proc/keys to verify
286       that the requested key has been instantiated:
287
288           $ ./t_request_key user mtk:key1 "Payload data"
289           $ grep '2dddaf50' /proc/keys
290           2dddaf50 I--Q---  1 perm 3f010000  1000  1000 user  mtk:key1: 12
291
292       For another example of the use of this program, see keyctl(2).
293
294   Program source
295
296       /* t_request_key.c */
297
298       #include <sys/types.h>
299       #include <keyutils.h>
300       #include <stdio.h>
301       #include <stdlib.h>
302       #include <string.h>
303
304       int
305       main(int argc, char *argv[])
306       {
307           key_serial_t key;
308
309           if (argc != 4) {
310               fprintf(stderr, "Usage: %s type description callout-data\n",
311                       argv[0]);
312               exit(EXIT_FAILURE);
313           }
314
315           key = request_key(argv[1], argv[2], argv[3],
316                             KEY_SPEC_SESSION_KEYRING);
317           if (key == -1) {
318               perror("request_key");
319               exit(EXIT_FAILURE);
320           }
321
322           printf("Key ID is %lx\n", (long) key);
323
324           exit(EXIT_SUCCESS);
325       }
326

COLOPHON

339       This page is part of release 4.15 of the Linux man-pages project.  A
340       description of the project, information about reporting bugs, and the
341       latest version of this page, can be found at
342       https://www.kernel.org/doc/man-pages/.
343
344
345
346Linux                             2017-09-15                    REQUEST_KEY(2)