package: keyutils

title: key.dns_resolver.conf(5)

summary: Kernel DNS resolver config

text:
# key.dns_resolver.conf(5)

## NAME
key.dns_resolver.conf - Kernel DNS resolver config

## DESCRIPTION
This file is used by the key.dns_resolver(5) program to set parameters. Unless otherwise overridden with the -c flag, the program reads:

/etc/key.dns_resolver.conf

Configuration options are given in key[=value] form, where value is optional. If present, the value may be surrounded by a pair of single ('') or double quotes ("") which will be stripped off. The special characters in the value may be escaped with a backslash to turn them into ordinary characters.

Lines beginning with a '#' are considered comments and ignored. A '#' symbol anywhere after the '=' makes the rest of the line into a comment unless the '#' is inside a quoted section or is escaped.

Leading and trailing spaces and spaces around the '=' symbol will be stripped off.

Available options include:

default_ttl=<number>

The number of seconds to set as the expiration on a cached record. This will be overridden if the program manages to retrieve TTL information along with the addresses (if, for example, it accesses the DNS directly). The default is 5 seconds. The value must be in the range 1 to INT_MAX.

The file can also include comments beginning with a '#' character unless otherwise suppressed by being inside a quoted value or being escaped with a backslash.

## FILES
/etc/key.dns_resolver.conf

## SEE ALSO
key.dns_resolver(8)

branch: sisyphus


request-key.conf

title: request-key.conf(5)

text:
# request-key.conf(5)

## NAME
request-key.conf - Instantiation handler configuration file

## DESCRIPTION
These files are used by the /sbin/request-key program to determine which program it should run to instantiate a key.

request-key looks for the best match, reading all the following files:

/etc/request-key.d/*.conf

/etc/request-key.conf

If it doesn't find a match, it will return an error and the kernel will automatically negate the key.

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.

In the files, any blank line or line beginning with a hash mark '#' is considered to be a comment and ignored.

All other lines are assumed to be command lines with a number of white space separated fields:

<op> <type> <description> <callout-info> <prog> <arg1> <arg2> ...

The first four fields are used to match the parameters passed to request-key by the kernel. op is the operation type; currently the only supported operation is "create".

type, description and callout-info match the three parameters passed to keyctl request2 or the request_key() system call. Each of these may contain one asterisk '*' character as a wildcard anywhere within the string.

Should a match be made, the program specified by <prog> will be exec'd. This must have a fully qualified path name. argv[0] will be set from the part of the program name that follows the last slash '/' character.

If the program name is prefixed with a pipe bar character '|', then the program will be forked and exec'd attached to three pipes. The callout information will be piped to it on it's 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-key will attempt to instantiate the key with the data read from stdout. If it fails in any other way, then request-key will attempt to execute the appropriate 'negate' operation command.

The program arguments can be substituted with various macros. Only complete argument substitution is supported - macro substitutions can't be embedded. All macros begin with a percent character '%'. An argument beginning with two percent characters will have one of them discarded.

The following macros are supported:

%o Operation type

%k Key ID

%t Key type

%d Key description

%c Callout information

%u Key UID

%g Key GID

%T Requestor's thread keyring

%P Requestor's process keyring

%S Requestor's session keyring

There's another macro substitution too that permits the interpolation of the contents of a key:

%{<type>:<description>}

This performs a lookup for a key of the given type and description on the requestor's 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.

## EXAMPLE
A basic file will be installed in the /etc. This will contain two debugging lines that can be used to test the installation:

create user debug:* negate /bin/keyctl negate %k 30 %S

create user debug:loop:* * |/bin/cat

create user debug:* * /usr/share/keyutils/request-key-debug.sh %k %d %c %S

negate * * * /bin/keyctl negate %k 30 %S

This is set up so that something like:

keyctl request2 user debug:xxxx negate

will create a negative user-defined key, something like:

keyctl request2 user debug:yyyy spoon

will create an instantiated user-defined key with "Debug spoon" as the payload, and something like:

keyctl request2 user debug:loop:zzzz abcdefghijkl

will create an instantiated user-defined key with the callout information as the payload.

## FILES
/etc/request-key.conf

/etc/request-key.d/*.conf

## SEE ALSO
keyctl(1), request-key.conf(5)


kiosk-profiles

package: kiosk-profiles

title: kiosk-profiles(5)

text:
# kiosk-profiles(5)

## NAME
kiosk-profiles - execution whitelists

## DESCRIPTION
/etc/alterator/kiosk/profiles contains all installed kiosk(1) profiles - executable lists.

Each executable is described on a separate line with two fields separated with exactly one space.

First field describes how executable is treated:

U - run securely (AT_SECURE is set)

u - run normally (AT_SECURE is not set)

Second field is path to executable.

If executable is a script, its shebang should be added into profile.

/etc/alterator/kiosk/profiles_enabled contains active kiosk(1) profiles.

Each active profile is a symlink to file in /etc/alterator/kiosk/profiles. Use acc(8) to activate or deactivate profiles.

## NOTES
Use dmesg(1) to track which executables are prevented to execute and add them to your profile if necessary as described above.

## BUGS
Report bugs to component kiosk-profiles on https://bugzilla.altlinux.org

## AUTHOR
Oleg Solovyov <mcpain@altlinux.org>