1REQUEST-KEY.CONF(5) Linux Key Management Utilities REQUEST-KEY.CONF(5)
2
6 request-key.conf - Instantiation handler configuration file
7
9 These files are used by the /sbin/request-key program to determine
10 which program it should run to instantiate a key.
11 request-key looks for the best match, reading all the following files:
13 /etc/request-key.d/*.conf
15 /etc/request-key.conf
16 If it doesn't find a match, it will return an error and the kernel will
18 automatically negate the key.
19 The best match is defined as the line with the shortest wildcard skips,
21 ranking the columns in order left to right. If two lines have the same
22 length skips, then the first read is the one taken.
23 In the files, any blank line or line beginning with a hash mark '#' is
25 considered to be a comment and ignored.
26 All other lines are assumed to be command lines with a number of white
28 space separated fields:
29 <op> <type> <description> <callout-info> <prog> <arg1> <arg2> ...
31 The first four fields are used to match the parameters passed to
33 request-key by the kernel. op is the operation type; currently the only
34 supported operation is "create".
35 type, description and callout-info match the three parameters passed to
37 keyctl request2 or the request_key() system call. Each of these may
38 contain one asterisk '*' character as a wildcard anywhere within the
39 string.
40 Should a match be made, the program specified by <prog> will be exec'd.
42 This must have a fully qualified path name. argv[0] will be set from
43 the part of the program name that follows the last slash '/' character.
44 If the program name is prefixed with a pipe bar character '|', then the
46 program will be forked and exec'd attached to three pipes. The callout
47 information will be piped to it on it's stdin and the intended payload
48 data will be retrieved from its stdout. Anything sent to stderr will be
49 posted in syslog. If the program exits 0, then /sbin/request-key will
50 attempt to instantiate the key with the data read from stdout. If it
51 fails in any other way, then request-key will attempt to execute the
52 appropriate 'negate' operation command.
53 The program arguments can be substituted with various macros. Only com‐
55 plete argument substitution is supported - macro substitutions can't be
56 embedded. All macros begin with a percent character '%'. An argument
57 beginning with two percent characters will have one of them discarded.
58 The following macros are supported:
60 %o Operation type
62 %k Key ID
63 %t Key type
64 %d Key description
65 %c Callout information
66 %u Key UID
67 %g Key GID
68 %T Requestor's thread keyring
69 %P Requestor's process keyring
70 %S Requestor's session keyring
71 There's another macro substitution too that permits the interpolation
73 of the contents of a key:
74 %{<type>:<description>}
76 This performs a lookup for a key of the given type and description on
78 the requestor's keyrings, and if found, substitutes the contents for
79 the macro. If not found an error will be logged and the key under con‐
80 struction will be negated.
81
83 A basic file will be installed in the /etc. This will contain two
84 debugging lines that can be used to test the installation:
85 create user debug:* negate /bin/keyctl negate %k 30 %S
87 create user debug:loop:* * |/bin/cat
88 create user debug:* * /usr/share/keyutils/request-key-debug.sh
89 %k %d %c %S
90 negate * * * /bin/keyctl negate %k 30 %S
91 This is set up so that something like:
93 keyctl request2 user debug:xxxx negate
95 will create a negative user-defined key, something like:
97 keyctl request2 user debug:yyyy spoon
99 will create an instantiated user-defined key with "Debug spoon" as the
101 payload, and something like:
102 keyctl request2 user debug:loop:zzzz abcdefghijkl
104 will create an instantiated user-defined key with the callout informa‐
106 tion as the payload.
107
109 /etc/request-key.conf
110 /etc/request-key.d/*.conf
111
113 keyctl(1), request-key.conf(5)
114Linux 15 November 2011 REQUEST-KEY.CONF(5)