NAME<\/a> request\u2212key.conf \u2212 Instantiation handler configuration file<\/p>\n These files are used by the \/sbin\/request\u2212key program to determine which program it should run to instantiate a key.<\/p>\n request\u2212key looks for the best match, reading all the following files:<\/p>\n
DESCRIPTION<\/a>
EXAMPLE<\/a>
FILES<\/a>
SEE ALSO<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
DESCRIPTION <\/a> <\/h2>\n
| <\/td>\n | <\/td>\n | \n \/etc\/request\u2212key.d\/*.conf<\/p>\n<\/td>\n<\/tr>\n |
| <\/td>\n | <\/td>\n | \n \/etc\/request\u2212key.conf<\/p>\n<\/td>\n<\/tr>\n<\/table>\n If it doesn\u2019t find a match, it will return an error and the kernel will automatically negate the key.<\/p>\n The best match is defined as the line with the shortest wildcard skips, ranking the columns in order left to right. If two lines have the same length skips, then the first read is the one taken.<\/p>\n In the files, any blank line or line beginning with a hash mark \u2019#\u2019 is considered to be a comment and ignored.<\/p>\n All other lines are assumed to be command lines with a number of white space separated fields:<\/p>\n The first four fields are used to match the parameters passed to request\u2212key by the kernel. op<\/i> is the operation type; currently the only supported operation is “create”.<\/p>\n type<\/i>, description<\/i> and callout\u2212info<\/i> match the three parameters passed to keyctl request2<\/b> or the request_key()<\/b> system call. Each of these may contain one asterisk \u2019*\u2019 character as a wildcard anywhere within the string.<\/p>\n Should a match be made, the program specified by If the program name is prefixed with a pipe bar character \u2019|\u2019, then the program will be forked and exec\u2019d attached to three pipes. The callout information will be piped to it on it\u2019s stdin and the intended payload data will be retrieved from its stdout. Anything sent to stderr will be posted in syslog. If the program exits 0, then \/sbin\/request\u2212key will attempt to instantiate the key with the data read from stdout. If it fails in any other way, then request\u2212key will attempt to execute the appropriate \u2019negate\u2019 operation command.<\/p>\n The program arguments can be substituted with various macros. Only complete argument substitution is supported – macro substitutions can\u2019t be embedded. All macros begin with a percent character \u2019%\u2019. An argument beginning with two percent characters will have one of them discarded.<\/p>\n The following macros are supported:<\/p>\n %o Operation type There\u2019s another macro substitution too that permits the interpolation of the contents of a key:<\/p>\n %{ This performs a lookup for a key of the given type and description on the requestor\u2019s keyrings, and if found, substitutes the contents for the macro. If not found an error will be logged and the key under construction will be negated.<\/p>\n A basic file will be installed in the \/etc. This will contain two debugging lines that can be used to test the installation:<\/p>\n create user debug:* negate \/bin\/keyctl negate %k 30 %S This is set up so that something like:<\/p>\n keyctl request2 user debug:xxxx negate<\/p>\n will create a negative user-defined key, something like:<\/p>\n keyctl request2 user debug:yyyy spoon<\/p>\n will create an instantiated user-defined key with “Debug spoon” as the payload, and something like:<\/p>\n keyctl request2 user debug:loop:zzzz abcdefghijkl<\/p>\n will create an instantiated user-defined key with the callout information as the payload.<\/p>\n |