title: selabel_file(5)

text:
# selabel_file(5)

## NAME
selabel_file - userspace SELinux labeling interface and configuration file format for the file contexts backend

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *path, int mode);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *path, int mode);

## DESCRIPTION
The file contexts backend maps from pathname/mode combinations into security contexts. It is used to find the appropriate context for each file when relabeling a file system. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes, however the following errno is clarified further for the file contexts backend:

ENOENT

No context corresponding to the path and mode was found - This will also be returned when the file contexts series of files have a context of <<none>> against the path (see the FILE FORMAT section).

The path argument should be set to the full pathname of the file whose assigned context is being checked. The mode argument should be set to the mode bits of the file, as determined by lstat(2). mode may be zero, however full matching may not occur.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw(3) behaves identically to selabel_lookup(3) but does not perform context translation.

The FILES section details the configuration files used to determine a file context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard file contexts file. This value is also used as the base name for determining the names of local customization files.

SELABEL_OPT_BASEONLY

A non-null value for this option indicates that any local customizations to the file contexts mapping should be ignored.

SELABEL_OPT_SUBSET

A non-null value for this option is interpreted as a path prefix, for example "/etc". Only file context specifications with starting with a first component that prefix matches the given prefix are loaded. This may increase lookup performance, however any attempt to look up a path not starting with the given prefix may fail. This optimization is no longer required due to the use of file_contexts.bin files and is deprecated.

## FILES
The file context files used to retrieve the default context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy file contexts location (as returned by selinux_file_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used.

If SELABEL_OPT_BASEONLY is set, then the following files will be processed:

1.

The mandatory file contexts file that is either the fully qualified file name from SELABEL_OPT_PATH.value or if NULL, then the path returned by selinux_file_context_path(3).

2.

The optional local and distribution substitution files that perform path aliasing on the 'in memory' version of the file contexts file.

These files have the same name as the mandatory file contexts file with the extensions .subs and .subs_dist added.

If the SELABEL_OPT_BASEONLY is not set, then the following files will be processed:

1.

The mandatory file contexts file that is either the fully qualified file name from SELABEL_OPT_PATH.value or if NULL, then the path returned by selinux_file_context_path(3).

2.

The optional local customizations file that has the same name as the mandatory file contexts file with the extension .local added.

selinux_file_context_local_path(3) will return the default path to this file.

3.

The optional user home directory customizations file that has the same name as the mandatory file contexts file with the extension .homedirs added.

selinux_file_context_homedir_path(3) will return the default path to this file.

4.

The optional local and distribution substitution files that perform any path aliasing on the 'in memory' version of the file contexts file (and the .local and/or .homedirs if present). These files have the same name as the mandatory file contexts file with the extensions .subs and .subs_dist added.

selinux_file_context_subs_path(3) and selinux_file_context_subs_dist_path(3) will return the default paths to these files.

The default file context series of files are:

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.local

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.homedirs

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.subs

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.subs_dist

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

Only the file_contexts file is mandatory, the remainder are optional.

The entries within the file contexts series of files are shown in the FILE FORMAT section.

## File Contexts Format
Each line within the file_contexts and the two customization files (.local and .homedirs) is as follows:

pathname [file_type] context

Where:

pathname An entry that defines the path to be labeled. May contain either a fully qualified path, or a Perl compatible regular expression (PCRE), describing fully qualified path(s). The only PCRE flag in use is PCRE2_DOTALL, which causes a wildcard '.' to match anything, including a new line. Strings representing paths are processed as bytes (as opposed to Unicode), meaning that non-ASCII characters are not matched by a single wildcard.

file_type An optional file type consisting of: -b - Block Device -c - Character Device

-d - Directory -p - Named Pipe

-l - Symbolic Link -s - Socket

-- - Ordinary file

context This entry can be either: a.

The security context that will be assigned to the file (i.e. returned as context).

b.

A value of <<none>> can be used to indicate that the matching files should not be re-labeled and causes selabel_lookup(3) to return -1 with errno set to ENOENT.

Example:

\# ./contexts/files/file_contexts

\# pathname file_type context

/.* system_u:object_r:default_t:s0

/[^/]+ -- system_u:object_r:etc_runtime_t:s0

/tmp/.* <<none>>

## Substitution File Format
Each line within the substitution files (.subs and .subs_dist) has the form:

subs_pathname pathname

Where:

pathname A path that matches an entry in one or more of the file contexts policy configuration file.

subs_pathname The path that will be aliased (considered equivalent) with pathname by the look up process.

Example:

\# ./contexts/files/file_contexts.subs

\# pathname subs_pathname

/myweb /var/www

/myspool /var/spool/mail Using the above example, when selabel_lookup(3) is passed a path of /myweb/index.html the function will substitute the /myweb component with /var/www, therefore the path used is:

/var/www/index.html

## NOTES
1.

If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

2.

If the size of file contexts series of files contain many entries, then selabel_open(3) may have a delay as it reads in the files, and if requested validates the entries.

3.

Depending on the version of SELinux it is possible that a file_contexts.template file may also be present, however this is now deprecated.

The template file has the same format as the file_contexts file and may also contain the keywords HOME_ROOT, HOME_DIR, ROLE and USER. This functionality has now been moved to the policy store and managed by semodule(8) and genhomedircon(8).

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_file_context_path(3), freecon(3), selinux_config(5), lstat(2), selinux_file_context_subs_path(3), selinux_file_context_subs_dist_path(3), selinux_file_context_homedir_path(3), selinux_file_context_local_path(3), semodule(8), genhomedircon(8)


package: libselinux-utils

title: selabel_media(5)

text:
# selabel_media(5)

## NAME
selabel_media - userspace SELinux labeling interface and configuration file format for the media contexts backend

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *device_name, int unused);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *device_name, int unused);

## DESCRIPTION
The media contexts backend maps from media device names such as "cdrom" or "floppy" into security contexts. It is used to find the appropriate context for establishing context mounts on these devices. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes.

The integer lookup argument is currently unused and should be set to zero.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw(3) behaves identically to selabel_lookup(3) but does not perform context translation.

The FILES section details the configuration files used to determine the media context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard media contexts file.

## FILES
The media context file used to retrieve a default context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy media contexts location (as returned by selinux_media_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used.

The default media contexts file is:

/etc/selinux/{SELINUXTYPE}/contexts/files/media

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line within the media file is as follows:

device_name context

Where:

device_name The media identifier (e.g. cdrom, floppy, disk and usb).

context The context to be used for labeling the device.

Example:

\# contexts/files/media

cdrom system_u:object_r:removable_device_t

floppy system_u:object_r:removable_device_t

disk system_u:object_r:fixed_disk_device_t

## NOTES
If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_media_context_path(3), freecon(3), selinux_config(5)


title: selabel_x(5)

text:
# selabel_x(5)

## NAME
selabel_x - userspace SELinux labeling interface and configuration file format for the X Window System contexts backend. This backend is also used to determine the default context for labeling remotely connected X clients

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *object_name, int object_type);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *object_name, int object_type);

## DESCRIPTION
The X contexts backend maps from X Window System object names into security contexts. It is used to find the appropriate context for X Window System objects whose significance and/or usage semantics are determined primarily by name. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes.

This backend is also used to determine the default context for labeling remotely connected X clients.

The object_type argument should be set to one of the following values:

SELABEL_X_PROP

The object_name argument specifies the name of a window property, such as "WM_NAME".

SELABEL_X_SELN

The object_name argument specifies the name of a selection, such as "PRIMARY".

SELABEL_X_EXT

The object_name argument specifies the name of a protocol extension, such as "RENDER".

SELABEL_X_EVENT

The object_name argument specifies the name of an event type, such as "X11:ButtonPress".

SELABEL_X_CLIENT

The object_name argument is ignored, however it should be set to either * (an asterisk or 'wildcard' that will select the default entry) or a specific entry such as "remote" in the X contexts file as shown in the EXAMPLE section. The default context for labeling remote X clients is then returned.

SELABEL_X_POLYPROP

Like SELABEL_X_PROP, but checks if the property was marked as being polyinstantiated. See NOTES below.

SELABEL_X_POLYSELN

Like SELABEL_X_SELN, but checks if the selection was marked as being polyinstantiated. See NOTES below.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw behaves identically to selabel_lookup but does not perform context translation.

The FILES section details the configuration files used to determine the X object context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard X contexts file (see the FILES section for details).

## FILES
The X context file used to retrieve a default context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy X contexts location (as returned by selinux_x_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used.

The default X object contexts file is:

/etc/selinux/{SELINUXTYPE}/contexts/x_contexts

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

The entries within the X contexts file are shown in the Object Name String Values and FILE FORMAT sections.

## Object Name String Values
The string name assigned to each object_type argument that can be present in the X contexts file are:

object_type

Text Name

SELABEL_X_PROP

property

SELABEL_X_SELN

selection

SELABEL_X_EXT

extension

SELABEL_X_EVENT

event

SELABEL_X_CLIENT

client

SELABEL_X_POLYPROP

poly_property

SELABEL_X_POLYSELN

poly_selection

## FILE FORMAT
Each line within the X contexts file is as follows:

object_type object_name context

Where:

object_type This is the string representation of the object type shown in the Object Name String Values section. There can be multiple lines with the same object_type string that will form a block of entries (each with a different object_name entry).

object_name These are the object names of the specific X-server resource such as PRIMARY, CUT_BUFFER0 etc. They are generally defined in the X-server source code (protocol.txt and BuiltInAtoms in the dix directory of the xorg-server source package). The entry can contain '*' for wildcard matching or '?' for substitution. Note that if the '*' is used, then be aware that the order of entries in the file is important. The '*' on its own is used to ensure a default fallback context is assigned and should be the last entry in the object_type block.

context The security context that will be applied to the object.

Example 1:

```
# object_type  object_name  context
selection      PRIMARY      system_u:object_r:clipboard_xselection_t:s0
selection      *            system_u:object_r:xselection_t:s0
```

Example 2 - This example shows how a client entry can be configured to ensure an entry is always found:

```
# object_type  object_name  context
client         *            system_u:object_r:remote_t:s0
```

## NOTES
1.

Properties and selections are marked as either polyinstantiated or not. For these name types, the "POLY" option searches only the names marked as being polyinstantiated, while the other option searches only the names marked as not being polyinstantiated. Users of the interface should check both mappings, optionally taking action based on the result (e.g. polyinstantiating the object).

2.

If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_x_context_path(3), freecon(3), selinux_config(5)


title: service_seusers(5)

text:
# service_seusers(5)

## NAME
service_seusers - The SELinux GNU/Linux user and service to SELinux user mapping configuration files

## DESCRIPTION
These are optional files that allow services to define an SELinux user when authenticating via SELinux-aware login applications such as PAM(8).

There is one file for each GNU/Linux user name that will be required to run a service with a specific SELinux user name.

The path for each configuration file is formed by the path returned by selinux_policy_root(3) with /logins/username appended (where username is a file representing the GNU/Linux user name). The default services directory is located at:

/etc/selinux/{SELINUXTYPE}/logins

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

getseuser(3) reads this file to map services to an SELinux user.

## FILE FORMAT
Each line within the username file is formatted as follows with each component separated by a colon:

service:seuser[:range]

Where:

service The service name used by the application.

seuser The SELinux user name.

range The range for MCS/MLS policies.

## EXAMPLES
Example 1 - for the 'root' user:

\# ./logins/root

ipa:user_u:s0

this_service:unconfined_u:s0

Example 2 - for GNU/Linux user 'rch':

\# ./logins/rch

ipa:unconfined_u:s0

that_service:unconfined_u:s0

## SEE ALSO
selinux(8), PAM(8), selinux_policy_root(3), getseuser(3), selinux_config(5)


seusers

title: seusers(5)

text:
# seusers(5)

## NAME
seusers - The SELinux GNU/Linux user to SELinux user mapping configuration file

## DESCRIPTION
The seusers file contains a list GNU/Linux user to SELinux user mapping for use by SELinux-aware login applications such as PAM(8).

selinux_usersconf_path(3) will return the active policy path to this file. The default SELinux users mapping file is located at:

/etc/selinux/{SELINUXTYPE}/seusers

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

getseuserbyname(3) reads this file to map a GNU/Linux user or group to an SELinux user.

## FILE FORMAT
Each line of the seusers configuration file consists of the following:

[%group_id]|[user_id]:seuser_id[:range]

Where:

group_id|user_id The GNU/Linux user id, or if preceded by the percentage (%) symbol, then a GNU/Linux group id.

An optional entry set to __default__ can be provided as a fall back if required.

seuser_id The SELinux user identity.

range The optional level or range for an MLS/MCS policy.

## EXAMPLE
\# ./seusers

system_u:system_u:s0-s15:c0.c255

root:root:s0-s15:c0.c255

fred:user_u:s0

__default__:user_u:s0

%user_group:user_u:s0

## SEE ALSO
selinux(8), PAM(8), selinux_usersconf_path(3), getseuserbyname(3), selinux_config(5)


title: user_contexts(5)

text:
# user_contexts(5)

## NAME
user_contexts - The SELinux user contexts configuration files

## DESCRIPTION
These optional user context configuration files contain entries that allow SELinux-aware login applications such as PAM(8) (running in their own process context), to determine the context that a users login session should run under.

SELinux-aware login applications generally use one or more of the following libselinux functions that read these files from the active policy path:

get_default_context(3)

get_ordered_context_list(3)

get_ordered_context_list_with_level(3)

get_default_context_with_level(3)

get_default_context_with_role(3)

get_default_context_with_rolelevel(3)

query_user_context(3)

manual_user_enter_context(3)

There can be one file for each SELinux user configured on the system. The file path is formed using the path returned by selinux_user_contexts_path(3) for the active policy, with the SELinux user name appended, for example:

/etc/selinux/{SELINUXTYPE}/contexts/users/unconfined_u

/etc/selinux/{SELINUXTYPE}/contexts/users/xguest_u

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

These files contain context information as described in the FILE FORMAT section.

## FILE FORMAT
Each line in the user context configuration file consists of the following:

login_process user_login_process

Where:

login_process This consists of a role:type[:range] entry that represents the login process context.

user_login_process This consists of a role:type[:range] entry that represents the user login process context.

## EXAMPLE
\# Example for xguest_u at /etc/selinux/targeted/contexts/users/xguest_u

system_r:crond_t:s0 xguest_r:xguest_t:s0

system_r:initrc_t:s0 xguest_r:xguest_t:s0

system_r:local_login_t:s0 xguest_r:xguest_t:s0

system_r:remote_login_t:s0 xguest_r:xguest_t:s0

system_r:sshd_t:s0 xguest_r:xguest_t:s0

system_r:xdm_t:s0 xguest_r:xguest_t:s0

xguest_r:xguest_t:s0 xguest_r:xguest_t:s0

## SEE ALSO
selinux(8), selinux_user_contexts_path(3), PAM(8), get_ordered_context_list(3), get_ordered_context_list_with_level(3), get_default_context_with_level(3), get_default_context_with_role(3), get_default_context_with_rolelevel(3), query_user_context(3), manual_user_enter_context(3), selinux_config(5)


title: virtual_domain_context(5)

text:
# virtual_domain_context(5)

## NAME
virtual_domain_context - The SELinux virtual machine domain context configuration file

## DESCRIPTION
The virtual_domain_context file contains a list of domain contexts that are available for use by the SELinux-aware virtualization API libvirt (see libvirtd(8)).

selinux_virtual_domain_context_path(3) will return the active policy path to this file. The default virtual domain context file is:

/etc/selinux/{SELINUXTYPE}/contexts/virtual_domain_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line in the file consists of an entry as follows:

user:role:type[:range]

Where:

user role type range A user, role, type and optional range (for MCS/MLS) separated by colons (:) that can be used as a virtual domain context.

## EXAMPLE
\# ./contexts/virtual_domain_context

system_u:object_r:svirt_t:s0

## SEE ALSO
selinux(8), libvirtd(8), selinux_virtual_domain_context_path(3), selinux_config(5)


title: virtual_image_context(5)

text:
# virtual_image_context(5)

## NAME
virtual_image_context - The SELinux virtual machine image context configuration file

## DESCRIPTION
The virtual_image_context file contains a list of image contexts for use by the SELinux-aware virtualization API libvirt (see libvirtd(8)).

selinux_virtual_image_context_path(3) will return the active policy path to this file. The default virtual image context file is:

/etc/selinux/{SELINUXTYPE}/contexts/virtual_image_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line in the file consists of an entry as follows:

user:role:type[:range]

Where:

user role type range A user, role, type and optional range (for MCS/MLS) separated by colons (:) that can be used as a virtual image context.

## EXAMPLE
\# ./contexts/virtual_image_context

system_u:object_r:svirt_image_t:s0

system_u:object_r:svirt_content_t:s0

## SEE ALSO
selinux(8), libvirtd(8), selinux_virtual_image_context_path(3), selinux_config(5)


semanage.conf

package: libsemanage

title: semanage.conf(5)

text:
# semanage.conf(5)

## NAME
semanage.conf - global configuration file for the SELinux Management library

## DESCRIPTION
The semanage.conf file is usually located under the directory /etc/selinux and it is used for run-time configuration of the behavior of the SELinux Management library.

Each line should contain a configuration parameter followed by the equal sign ("=") and then followed by the configuration value for that parameter. Anything after the "#" symbol is ignored similarly to empty lines.

The following parameters are allowed:

module-store

Specify how the SELinux Management library should interact with the SELinux policy store. When set to "direct", the SELinux Management library writes to the SELinux policy module store directly (this is the default setting). Otherwise a socket path or a server name can be used for the argument. If the argument begins with "/" (as in "/foo/bar"), it represents the path to a named socket that should be used to connect the policy management server. If the argument does not begin with a "/" (as in "example.com:4242"), it should be interpreted as the name of a remote policy management server to be used through a TCP connection (default port is 4242 unless a different one is specified after the server name using the colon to separate the two fields).

root

Specify an alternative root path to use for the store. The default is "/"

store-root

Specify an alternative store_root path to use. The default is "/var/lib/selinux"

compiler-directory

Specify an alternative directory that contains HLL to CIL compilers. The default value is "/usr/libexec/selinux/hll".

ignore-module-cache

Whether or not to ignore the cache of CIL modules compiled from HLL. It can be set to either "true" or "false" and is set to "false" by default. If the cache is ignored, then all CIL modules are recompiled from their HLL modules.

policy-version

When generating the policy, by default semanage will set the policy version to POLICYDB_VERSION_MAX, as defined in <sepol/policydb/policydb.h>. Change this setting if a different version needs to be set for the policy.

target-platform

The target platform to generate policies for. Valid values are "selinux" and "xen", and is set to "selinux" by default.

expand-check

Whether or not to check "neverallow" rules when executing all semanage command. It can be set to either "0" (disabled) or "1" (enabled) and by default it is enabled. There might be a large penalty in execution time if this option is enabled.

file-mode

By default the permission mode for the run-time policy files is set to 0644.

save-previous

It controls whether the previous module directory is saved after a successful commit to the policy store and it can be set to either "true" or "false". By default it is set to "false" (the previous version is deleted).

save-linked

It controls whether the previously linked module is saved (with name "base.linked") after a successful commit to the policy store. It can be set to either "true" or "false" and by default it is set to "false" (the previous module is deleted).

ignoredirs

List, separated by ";", of directories to ignore when setting up users homedirs. Some distributions use this to stop labeling /root as a homedir.

usepasswd

Whether or not to enable the use getpwent() to obtain a list of home directories to label. It can be set to either "true" or "false". By default it is set to "true".

disable-genhomedircon

It controls whether or not the genhomedircon function is executed when using the semanage command and it can be set to either "false" or "true". By default the genhomedircon functionality is enabled (equivalent to this option set to "false").

handle-unknown

This option overrides the kernel behavior for handling permissions defined in the kernel but missing from the actual policy. It can be set to "deny", "reject" or "allow". By default the setting from the policy is taken.

bzip-blocksize

It should be in the range 0-9. A value of 0 means no compression. By default the bzip block size is set to 9 (actual block size value is obtained after multiplication by 100000).

bzip-small

When set to "true", the bzip algorithm shall try to reduce its system memory usage. It can be set to either "true" or "false" and by default it is set to "false".

remove-hll

When set to "true", HLL files will be removed after compilation into CIL. In order to delete HLL files already compiled into CIL, modules will need to be recompiled with the ignore-module-cache option set to 'true' or using the ignore-module-cache option with semodule. The remove-hll option can be set to either "true" or "false" and by default it is set to "false". Please note that since this option deletes all HLL files, an updated HLL compiler will not be able to recompile the original HLL file into CIL. In order to compile the original HLL file into CIL, the same HLL file will need to be reinstalled.

optimize-policy

When set to "true", the kernel policy will be optimized upon rebuilds. It can be set to either "true" or "false" and by default it is set to "true".

multiple-decls

When set to "true", duplicate type, type attribute, and role declarations will be allowed. It can be set to either "true" or "false" and by default it is set to "true".

For certain tasks the SELinux Management library resorts to running external commands. For the following commands their path and arguments can be overridden:

load_policy

Command to load a kernel policy. Requires no argument. Defaults to /sbin/load_policy with no arguments.

setfiles

Command to verify file context definitions. Requires two arguments, the path to the kernel policy and the path to the file context definition file. Defaults to /sbin/setfiles with the arguments '-q -c $@ $<'.

sefcontext_compile

Command to compile a file context definition file. Requires one argument, the path to the to be compiled file context definition file. Defaults to /sbin/sefcontext_compile with the argument '$@'.

Either path or args can be omitted. The argument string must contain '$@' for the first required argument, and '$<' for the second one. The syntax for overriding an external command property is:

[name]

path = /path/to/command

args = --flag

[end]

Example

[sefcontext_compile]

path = /usr/sbin/sefcontext_compile

args = -r $@

[end]

Optionally the SELinux Management library can invoke external commands to verify source modules (verify module), linked modules (verify linked), and kernel policies (verify kernel). The syntax is identical to the above command overrides. The program should exit with a value of 0 on success, and non zero on failure.

## SEE ALSO
semanage(8)

## AUTHOR
This manual page was written by Guido Trentalancia <guido@trentalancia.com>.

The SELinux management library was written by Tresys Technology LLC and Red Hat Inc.


package: libsofthsm

title: softhsm2.conf(5)

summary: SoftHSM configuration file

text:
# softhsm2.conf(5)

## NAME
softhsm2.conf - SoftHSM configuration file

## SYNOPSIS
softhsm2.conf

## DESCRIPTION
This is the configuration file for SoftHSM. It can be found on a default location, but can also be relocated by using the environment variable. Any configuration must be done according to the file format found in this document.

## FILE FORMAT
Each configuration option is a pair of name and value separated by a equality sign. The configuration option must be located on a single line.

```
<name> = <value>
```

It is also possible to add comments in the file by using the hash sign. Anything after the hash sign will be ignored.

```
# A comment
```

```
Any empty lines or lines that does not have the correct format will be ignored.
```

## DIRECTORIES.TOKENDIR
The location where SoftHSM can store the tokens.

```
directories.tokendir = /var/lib/softhsm/tokens/
```

## OBJECTSTORE.BACKEND
The backend to use by SoftHSM to store token objects. Either "file" or "db" is supported. In order to use the "db" backend, the SoftHSM build needs to be configured with "configure --with-objectstore-backend-db"

```
objectstore.backend = file
```

## LOG.LEVEL
The log level which can be set to ERROR, WARNING, INFO or DEBUG.

```
log.level = INFO
```

## SLOTS.REMOVABLE
If set to true CKF_REMOVABLE_DEVICE is set in the flags returned by C_GetSlotInfo. Default is false.

```
slots.removable = true
```

## TOKEN.MECHANISMS
Allows to enable and disable any of the PKCS#11 mechanisms reported in the C_GetMechanismList(). The option accepts string argument containing the comma separated list of all algorithms that should be enabled (do not forget about the keygen mechanisms). The list can be prefixed with minus sign "-" to list only the disabled mechanisms. Additionally, special keyword ALL can be used to enable all the known mechanisms (default). Unknown mechanisms are ignored. This option has higher priority than the CKA_ALLOWED_MECHANISMS attribute on the key objects.

```
slots.mechanisms = ALL
```

## LIBRARY.RESET_ON_FORK
If set to true, the library will reset the state on fork. Default is false.

```
library.reset_on_fork = true
```

## ENVIRONMENT
SOFTHSM2_CONF

When defined, the value will be used as path to the configuration file.

## FILES
~/.config/softhsm2/softhsm2.conf

default user-specific location of the SoftHSM configuration file; if it exists it will override the system wide configuration

/etc/softhsm2.conf

default system-wide location of the SoftHSM configuration file

/etc/softhsm2.conf.sample

an example of a SoftHSM configuration file

## AUTHOR
Written by Rickard Bellgrim, Francis Dupont, René Post, and Roland van Rijswijk.

## SEE ALSO
softhsm2-keyconv(1), softhsm2-migrate(1), softhsm2-util(1)


sss-certmap

title: sss-certmap(5)

text:
# sss-certmap(5)

## NAME
sss-certmap - SSSD Certificate Matching and Mapping Rules

## DESCRIPTION
The manual page describes the rules which can be used by SSSD and other components to match X.509 certificates and map them to accounts.

Each rule has four components, a “priority”, a “matching rule”, a “mapping rule” and a “domain list”. All components are optional. A missing “priority” will add the rule with the lowest priority. The default “matching rule” will match certificates with the digitalSignature key usage and clientAuth extended key usage. If the “mapping rule” is empty the certificates will be searched in the userCertificate attribute as DER encoded binary. If no domains are given only the local domain will be searched.

To allow extensions or completely different style of rule the “mapping” and “matching rules” can contain a prefix separated with a ':' from the main part of the rule. The prefix may only contain upper-case ASCII letters and numbers. If the prefix is omitted the default type will be used which is 'KRB5' for the matching rules and 'LDAP' for the mapping rules.

The 'sssctl' utility provides the 'cert-eval-rule' command to check if a given certificate matches a matching rules and how the output of a mapping rule would look like.

## RULE COMPONENTS

### PRIORITY
The rules are processed by priority while the number '0' (zero) indicates the highest priority. The higher the number the lower is the priority. A missing value indicates the lowest priority. The rules processing is stopped when a matched rule is found and no further rules are checked.

Internally the priority is treated as unsigned 32bit integer, using a priority value larger than 4294967295 will cause an error.

If multiple rules have the same priority and only one of the related matching rules applies, this rule will be chosen. If there are multiple rules with the same priority which matches, one is chosen but which one is undefined. To avoid this undefined behavior either use different priorities or make the matching rules more specific e.g. by using distinct <ISSUER> patterns.

### MATCHING RULE
The matching rule is used to select a certificate to which the mapping rule should be applied. It uses a system similar to the one used by “pkinit_cert_match” option of MIT Kerberos. It consists of a keyword enclosed by '<' and '>' which identified a certain part of the certificate and a pattern which should be found for the rule to match. Multiple keyword pattern pairs can be either joined with '&&' (and) or '||' (or).

Given the similarity to MIT Kerberos the type prefix for this rule is 'KRB5'. But 'KRB5' will also be the default for “matching rules” so that "<SUBJECT>.*,DC=MY,DC=DOMAIN" and "KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN" are equivalent.

The available options are:

<SUBJECT>regular-expression

With this a part or the whole subject name of the certificate can be matched. For the matching POSIX Extended Regular Expression syntax is used, see regex(7) for details. For the matching the subject name stored in the certificate in DER encoded ASN.1 is converted into a string according to RFC 4514. This means the most specific name component comes first. Please note that not all possible attribute names are covered by RFC 4514. The names included are 'CN', 'L', 'ST', 'O', 'OU', 'C', 'STREET', 'DC' and 'UID'. Other attribute names might be shown differently on different platform and by different tools. To avoid confusion those attribute names are best not used or covered by a suitable regular-expression.

Example: <SUBJECT>.*,DC=MY,DC=DOMAIN

Please note that the characters "^.[$()|*+?{\" have a special meaning in regular expressions and must be escaped with the help of the '\' character so that they are matched as ordinary characters.

Example: <SUBJECT>^CN=.* \(Admin\),DC=MY,DC=DOMAIN$

<ISSUER>regular-expression

With this a part or the whole issuer name of the certificate can be matched. All comments for <SUBJECT> apply her as well. Example: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$

<KU>key-usage

This option can be used to specify which key usage values the certificate should have. The following values can be used in a comma separated list:

•digitalSignature

•nonRepudiation

•keyEncipherment

•dataEncipherment

•keyAgreement

•keyCertSign

•cRLSign

•encipherOnly

•decipherOnly

A numerical value in the range of a 32bit unsigned integer can be used as well to cover special use cases.

Example: <KU>digitalSignature,keyEncipherment

<EKU>extended-key-usage

This option can be used to specify which extended key usage the certificate should have. The following value can be used in a comma separated list:

•serverAuth

•clientAuth

•codeSigning

•emailProtection

•timeStamping

•OCSPSigning

•KPClientAuth

•pkinit

•msScLogin

Extended key usages which are not listed above can be specified with their OID in dotted-decimal notation.

Example: <EKU>clientAuth,1.3.6.1.5.2.3.4

<SAN>regular-expression

To be compatible with the usage of MIT Kerberos this option will match the Kerberos principals in the PKINIT or AD NT Principal SAN as <SAN:Principal> does. Example: <SAN>.*@MY\.REALM

<SAN:Principal>regular-expression

Match the Kerberos principals in the PKINIT or AD NT Principal SAN. Example: <SAN:Principal>.*@MY\.REALM

<SAN:ntPrincipalName>regular-expression

Match the Kerberos principals from the AD NT Principal SAN. Example: <SAN:ntPrincipalName>.*@MY.AD.REALM

<SAN:pkinit>regular-expression

Match the Kerberos principals from the PKINIT SAN. Example: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM

<SAN:dotted-decimal-oid>regular-expression

Take the value of the otherName SAN component given by the OID in dotted-decimal notation, interpret it as string and try to match it against the regular expression. Example: <SAN:1.2.3.4>test

<SAN:otherName>base64-string

Do a binary match with the base64 encoded blob against all otherName SAN components. With this option it is possible to match against custom otherName components with special encodings which could not be treated as strings. Example: <SAN:otherName>MTIz

<SAN:rfc822Name>regular-expression

Match the value of the rfc822Name SAN. Example: <SAN:rfc822Name>.*@email\.domain

<SAN:dNSName>regular-expression

Match the value of the dNSName SAN. Example: <SAN:dNSName>.*\.my\.dns\.domain

<SAN:x400Address>base64-string

Binary match the value of the x400Address SAN. Example: <SAN:x400Address>MTIz

<SAN:directoryName>regular-expression

Match the value of the directoryName SAN. The same comments as given for <ISSUER> and <SUBJECT> apply here as well. Example: <SAN:directoryName>.*,DC=com

<SAN:ediPartyName>base64-string

Binary match the value of the ediPartyName SAN. Example: <SAN:ediPartyName>MTIz

<SAN:uniformResourceIdentifier>regular-expression

Match the value of the uniformResourceIdentifier SAN. Example: <SAN:uniformResourceIdentifier>URN:.*

<SAN:iPAddress>regular-expression

Match the value of the iPAddress SAN. Example: <SAN:iPAddress>192\.168\..*

<SAN:registeredID>regular-expression

Match the value of the registeredID SAN as dotted-decimal string. Example: <SAN:registeredID>1\.2\.3\..*

### MAPPING RULE
The mapping rule is used to associate a certificate with one or more accounts. A Smartcard with the certificate and the matching private key can then be used to authenticate as one of those accounts.

Currently SSSD basically only supports LDAP to lookup user information (the exception is the proxy provider which is not of relevance here). Because of this the mapping rule is based on LDAP search filter syntax with templates to add certificate content to the filter. It is expected that the filter will only contain the specific data needed for the mapping and that the caller will embed it in another filter to do the actual search. Because of this the filter string should start and stop with '(' and ')' respectively.

In general it is recommended to use attributes from the certificate and add them to special attributes to the LDAP user object. E.g. the 'altSecurityIdentities' attribute in AD or the 'ipaCertMapData' attribute for IPA can be used.

This should be preferred to read user specific data from the certificate like e.g. an email address and search for it in the LDAP server. The reason is that the user specific data in LDAP might change for various reasons would break the mapping. On the other hand it would be hard to break the mapping on purpose for a specific user.

The default “mapping rule” type is 'LDAP' which can be added as a prefix to a rule like e.g. 'LDAP:(userCertificate;binary={cert!bin})'. There is an extension called 'LDAPU1' which offer more templates for more flexibility. To allow older versions of this library to ignore the extension the prefix 'LDAPU1' must be used when using the new templates in a “mapping rule” otherwise the old version of this library will fail with a parsing error. The new templates are described in section the section called “LDAPU1 extension”.

The templates to add certificate data to the search filter are based on Python-style formatting strings. They consist of a keyword in curly braces with an optional sub-component specifier separated by a '.' or an optional conversion/formatting option separated by a '!'. Allowed values are:

{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

This template will add the full issuer DN converted to a string according to RFC 4514. If X.500 ordering (most specific RDN comes last) an option with the '_x500' prefix should be used. The conversion options starting with 'ad_' will use attribute names as used by AD, e.g. 'S' instead of 'ST'.

The conversion options starting with 'nss_' will use attribute names as used by NSS.

The default conversion option is 'nss', i.e. attribute names according to NSS and LDAP/RFC 4514 ordering.

Example: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})

{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

This template will add the full subject DN converted to string according to RFC 4514. If X.500 ordering (most specific RDN comes last) an option with the '_x500' prefix should be used. The conversion options starting with 'ad_' will use attribute names as used by AD, e.g. 'S' instead of 'ST'.

The conversion options starting with 'nss_' will use attribute names as used by NSS.

The default conversion option is 'nss', i.e. attribute names according to NSS and LDAP/RFC 4514 ordering.

Example: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})

{cert[!(bin|base64)]}

This template will add the whole DER encoded certificate as a string to the search filter. Depending on the conversion option the binary certificate is either converted to an escaped hex sequence '\xx' or base64. The escaped hex sequence is the default and can e.g. be used with the LDAP attribute 'userCertificate;binary'. Example: (userCertificate;binary={cert!bin})

{subject_principal[.short_name]}

This template will add the Kerberos principal which is taken either from the SAN used by pkinit or the one used by AD. The 'short_name' component represents the first part of the principal before the '@' sign. Example: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))

{subject_pkinit_principal[.short_name]}

This template will add the Kerberos principal which is given by the SAN used by pkinit. The 'short_name' component represents the first part of the principal before the '@' sign. Example: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))

{subject_nt_principal[.short_name]}

This template will add the Kerberos principal which is given by the SAN used by AD. The 'short_name' component represent the first part of the principal before the '@' sign. Example: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))

{subject_rfc822_name[.short_name]}

This template will add the string which is stored in the rfc822Name component of the SAN, typically an email address. The 'short_name' component represents the first part of the address before the '@' sign. Example: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))

{subject_dns_name[.short_name]}

This template will add the string which is stored in the dNSName component of the SAN, typically a fully-qualified host name. The 'short_name' component represents the first part of the name before the first '.' sign. Example: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))

{subject_uri}

This template will add the string which is stored in the uniformResourceIdentifier component of the SAN. Example: (uri={subject_uri})

{subject_ip_address}

This template will add the string which is stored in the iPAddress component of the SAN. Example: (ip={subject_ip_address})

{subject_x400_address}

This template will add the value which is stored in the x400Address component of the SAN as escaped hex sequence. Example: (attr:binary={subject_x400_address})

{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

This template will add the DN string of the value which is stored in the directoryName component of the SAN. Example: (orig_dn={subject_directory_name})

{subject_ediparty_name}

This template will add the value which is stored in the ediPartyName component of the SAN as escaped hex sequence. Example: (attr:binary={subject_ediparty_name})

{subject_registered_id}

This template will add the OID which is stored in the registeredID component of the SAN as a dotted-decimal string. Example: (oid={subject_registered_id})

LDAPU1 extension

The following templates are available when using the 'LDAPU1' extension:

{serial_number[!(dec|hex[_ucr])]}

This template will add the serial number of the certificate. By default it will be printed as a hexadecimal number with lower-case letters. With the formatting option '!dec' the number will be printed as decimal string. The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.

Example: LDAPU1:(serial={serial_number})

{subject_key_id[!hex[_ucr]]}

This template will add the subject key id of the certificate. By default it will be printed as a hexadecimal number with lower-case letters. The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.

Example: LDAPU1:(ski={subject_key_id})

{cert[!DIGEST[_ucr]]}

This template will add the hexadecimal digest/hash of the certificate where DIGEST must be replaced with the name of a digest/hash function supported by OpenSSL, e.g. 'sha512'. The hexadecimal output can be printed with upper-case letters ('!sha512_u'), with a colon separating the hexadecimal bytes ('!sha512_c') or with the hexadecimal bytes in reverse order ('!sha512_r'). The postfix letters can be combined so that e.g. '!sha512_uc' will produce a colon-separated hexadecimal string with upper-case letters.

Example: LDAPU1:(dgst={cert!sha256})

{subject_dn_component[(.attr_name|[number]]}

This template will add an attribute value of a component of the subject DN, by default the value of the most specific component. A different component can be selected by either attribute name, e.g. {subject_dn_component.uid} or by position, e.g. {subject_dn_component.[2]} where positive numbers start counting from the most specific component and negative numbers start counting from the least specific component. Attribute name and the position can be combined as e.g. {subject_dn_component.uid[2]} which means that the name of the second component must be 'uid'.

Example: LDAPU1:(uid={subject_dn_component.uid})

{issuer_dn_component[(.attr_name|[number]]}

This template will add an attribute value of a component of the issuer DN, by default the value of the most specific component. See 'subject_dn_component' for details about the attribute name and position specifiers.

Example: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})

{sid[.rid]}

This template will add the SID if the corresponding extension introduced by Microsoft with the OID 1.3.6.1.4.1.311.25.2 is available. With the '.rid' selector only the last component, i.e. the RID, will be added. Example: LDAPU1:(objectsid={sid})

### DOMAIN LIST
If the domain list is not empty users mapped to a given certificate are not only searched in the local domain but in the listed domains as well as long as they are know by SSSD. Domains not know to SSSD will be ignored.

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/


netconfig

package: libtirpc

title: netconfig(5)

summary: network configuration data base

text:
# netconfig(5)

## NAME
netconfig — network configuration data base

## SYNOPSIS
/etc/netconfig

## DESCRIPTION
The netconfig file defines a list of “transport names”, describing their semantics and protocol. In FreeBSD, this file is only used by the RPC library code.

Entries have the following format:

network_id semantics flags family protoname device libraries

Entries consist of the following fields:

network_id

The name of the transport described.

semantics

Describes the semantics of the transport. This can be one of: tpi_clts

Connectionless transport.

tpi_cots

Connection-oriented transport

tpi_cots_ord

Connection-oriented, ordered transport.

tpi_raw

A raw connection.

flags

This field is either blank (specified by “-”), or contains a “v”, meaning visible to the getnetconfig(3) function.

family

The protocol family of the transport. This is currently one of: inet6

The IPv6 (PF_INET6) family of protocols.

inet

The IPv4 (PF_INET) family of protocols.

loopback

The PF_LOCAL protocol family.

protoname

The name of the protocol used for this transport. Can currently be either udp, tcp or empty.

device

This field is always empty in FreeBSD.

libraries

This field is always empty in FreeBSD.

The order of entries in this file will determine which transport will be preferred by the RPC library code, given a match on a specified network type. For example, if a sample network config file would look like this:

```
udp6       tpi_clts      v     inet6    udp     -       -
tcp6       tpi_cots_ord  v     inet6    tcp     -       -
udp        tpi_clts      v     inet     udp     -       -
tcp        tpi_cots_ord  v     inet     tcp     -       -
rawip      tpi_raw       -     inet      -      -       -
local      tpi_cots_ord  -     loopback  -      -       -
```

then using the network type udp in calls to the RPC library function (see rpc(3)) will make the code first try udp6, and then udp.

getnetconfig(3) and associated functions will parse this file and return structures of the following format:

```
struct netconfig {
    char *nc_netid;              /* Network ID */
    unsigned long nc_semantics;  /* Semantics (see below) */
    unsigned long nc_flag;       /* Flags (see below) */
    char *nc_protofmly;          /* Protocol family */
    char *nc_proto;              /* Protocol name */
    char *nc_device;             /* Network device pathname (unused) */
    unsigned long nc_nlookups;   /* Number of lookup libs (unused) */
    char **nc_lookups;           /* Names of the libraries (unused) */
    unsigned long nc_unused[9];  /* reserved */
};
```

## FILES
/etc/netconfig

## SEE ALSO
getnetconfig(3), getnetpath(3)


fapi-config

title: fapi-config(5)

text:
# fapi-config(5)

## SEE ALSO
fapi-profile(5)

## DESCRIPTION
FAPI configuration file

The FAPI parameters which can be adjusted via the configuration file are;

•

profile_name: Name of the default cryptographic profile chosen from the profile_dir directory.

•

profile_dir: Directory that contains all cryptographic profiles known to FAPI.

•

user_dir: The directory where user objects are stored.

•

system_dir: The directory where system objects, policies, and imported objects are stored.

•

tcti: The TCTI interface which will be used.

•

system_pcrs: The PCR registers which are used by the system.

•

log_dir: The directory for the event log.

•

ek_cert_less: A switch to disable certificate verification (optional).

•

ek_fingerprint: The fingerprint of the endorsement key (optional).

If not otherwise specified during TSS installation, the default location for the exemplary profiles is /etc/tpm2-tss/profiles/ and /etc/tpm2-tss/ for the FAPI configuration file. The environment variable TSS2_FAPICONF can be used to set an alternative pathname for the FAPI configuration file. If the system measurement files (IMA and bios) do not exist /dev/null will be used for firmware_log_file and ima_log_file.

## EXAMPLES
The FAPI configuration file is JSON encoded:

```
{
     "profile_name": "P_ECCP256SHA256",
     "profile_dir": "/etc/tpm2-tss/fapi-profiles/",
     "user_dir": "~/.local/share/tpm2-tss/user/keystore/",
     "system_dir": "/home/myhome/keystore/system/keystore",
     "tcti": "",
     "system_pcrs" : [0, 1, 2, 3, 4, 5, 6, 7],
     "log_dir" : "/home/myhome/eventlog/",
     "firmware_log_file" : "/sys/kernel/security/tpm0/binary_bios_measurements",
      "ima_log_file" : "/sys/kernel/security/ima/binary_runtime_measurements"
}

```

For this example the default TCTI of the system will be used. The certificates for the stored endorsement keys will be checked. If the certificate checking is not needed the option:

"ek_cert_less": "yes" can be added to the config file. Alternative to the standard certificate checking a fingerprint (hash of the public key) for the stored endorsement key can be defined in the config file:

"ek_fingerprint": { "hashAlg" : "sha256", "digest" : "9e56...214d" }

## COLOPHON
This page is part of release 4.1.3 of Open Source implementation of the TCG TPM2 Software Stack (TSS2). A description of the project, information about reporting bugs, and the latest version of this page can be found at https://github.com/tpm2-software/tpm2-tss/.


fapi-profile

title: fapi-profile(5)

text:
# fapi-profile(5)

## SEE ALSO
fapi-config(5)

## DESCRIPTION
FAPI Cryptographic Profile

Cryptographic profiles determine the cryptographic algorithms and parameters for all keys and operations of a specific TPM interaction. The values affected by these profiles are:

•

the name hash algorithm

•

asymmetric signature algorithm, scheme and parameters (such as curve, keysize, default padding, hash, etc)

•

PCR bank selection (which PCR banks shall be extended, quoted and read)

Two exemplary profiles for RSA and ECC are installed with the TSS. By default, the RSA cryptographic profile is activated. The user is free to create own cryptographic profiles according to his needs.

Specific profiles are activated in the FAPI configuration file. If not otherwise specified during TSS installation, the default location for the exemplary profiles is /etc/tpm2-tss/profiles/ and /etc/tpm2-tss/ for the FAPI configuration file.

The parameters of the profile are:

•

type: The asymmetric algorithm used for this profile.

•

nameAlg: The hash algorithm which will be used for sessions and keys.

•

srk_template: The type definition for the /SRK object. See the type parameter of Fapi_CreateKey.

•

srk_description: The description to be set for the /EK object. See Fapi_GetDescription.

•

ek_template: The type definition for the /EK object. See the type parameter of Fapi_CreateKey.

•

ek_description: The description to be set for the /SRK object. See Fapi_GetDescription.

•

ecc_signing_scheme: The signing scheme used for ECC keys.

•

rsa_signing_scheme: The signing scheme used for RSA keys.

•

keyBits: The key size for RSA keys.

•

exponent: The exponent of RSA keys.

•

sym_mode: The block cipher mode for symmetric encryption.

•

sym_parameters: The algorithm and parameters used for symmetric encryption.

•

sym_block_size: The block size used for symmetric encryption.

•

session_symmetric: The algorithm and parameters used for parameter encryption of a session (The same format and default as sym_parameters).

•

pcr_selection: The PCR registers and banks used by FAPI.

•

curveID: The curve ID for ECC keys.

•

ek_policy: The JSON encoded policy for the /EK object.

•

srk_policy: The JSON encoded policy for the /SRK object.

•

eh_policy: The JSON encoded policy for the endorsement hierarchy /HE.

•

sh_policy: The JSON encoded policy for the owner hierarchy /HS.

•

lockout_policy: The JSON encoded policy for the lockout hierarchy /LOCKOUT.

•

newMaxTries: Count of authorization failures before the lockout is imposed. If not set the default is 5.

•

newRecoveryTime: Time in seconds before the authorization failure count is automatically decremented. A value of zero indicates that DA protection is disabled. If not set the default is 1000.

•

lockoutRecovery: Time in seconds after a lockoutAuth failure before use of lockoutAuth is allowed A value of zero indicates that a reboot is required. If not set the default is 1000.

•

ignore_ek_template: Ignore EK template stored in NV ram. If not set the default is "no".

## EXAMPLES
The following JSON encoded example shows the standard profile for ECC keys:

```
{
    "type": "TPM2_ALG_ECC",
    "nameAlg":"TPM2_ALG_SHA256",
    "srk_template": "system,restricted,decrypt,0x81000001",
    "srk_description": "Storage root key SRK",
    "ek_template":  "system,restricted,decrypt",
    "ek_description": "Endorsement key EK",
    "ecc_signing_scheme": {
        "scheme":"TPM2_ALG_ECDSA",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        },
    },
    "sym_mode":"TPM2_ALG_CFB",
    "sym_parameters": {
        "algorithm":"TPM2_ALG_AES",
        "keyBits":"128",
        "mode":"TPM2_ALG_CFB"
    },
    "sym_block_size": 16,
    "pcr_selection": [
       { "hash": "TPM2_ALG_SHA1",
         "pcrSelect": [ ],
       },
       { "hash": "TPM2_ALG_SHA256",
         "pcrSelect": [ 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 ]
       }
    ],
    "curveID": "TPM2_ECC_NIST_P256",
    "ek_policy": {
        "description": "Endorsement hierarchy used for policy secret.",
        "policy":[
            {
                "type":"POLICYSECRET",
                "objectName": "4000000b",
            }
        ]
    }
}

```

Beside the cryptographic parameters descriptions for the storage root key and the endorsement key can be set. For the endorsement hierarchy the policy "ek_policy" is set according to the TCG Credential profile EK 2.0. The values of the constants are the same as the constants defined in the TSS header files, where the prefix TPM2_ can be omitted.

The key type of the storage root key and the endorsement key is defined by the JSON fields srk_template and ek_template. The type consists of a list of comma and/or space separated keywords. If a keyword is not present the inverse of the reference TPM attribute bits SHALL be set or cleared. The keywords are:

•

sign: Sets the sign attribute of a key.

•

decrypt: Sets the decrypt attribute of a key.

•

If neither sign nor decrypt are provided, both attributes SHALL be set.

•

restricted: Sets the restricted attribute of a key.

•

If restricted is set, either sign or decrypt (but not both) SHALL be set.

•

noda: Sets the noda attribute of a key or NV index.

•

A hexadecimal number: Marks a key object to be made persistent and sets the persistent object handle to this value.

The RSA profile has specific values for the signing scheme and the decrypt scheme:

```
      "rsa_signing_scheme": {
        "scheme":"TPM2_ALG_RSAPSS",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        }
    "rsa_decrypt_scheme": {
        "scheme":"TPM2_ALG_OAEP",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        }
    },

```

Possible values for the signing schemes are:

•

RSA: RSASSA, RSAPSS

•

ECC: ECDSA, ECDAA

Possible modes for symmetric encryption are:

•

CTR, OFB, CBC, CFB, ECB, NULL

Possible modes for the RSA decrypt scheme are:

•

RSAES, OAEP

The following curve ids can be used:

•

ECC_NIST_P192, ECC_NIST_P224, ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, ECC_BN_P256, ECC_BN_P638, ECC_SM2_P256

```
If the PCR registers 0 to 10 are extended by BIOS and IMA in the SHA1 bank the following PCR selection should
be used to enable the use of FAPI quote and verify quote:
    "pcr_selection": [
       { "hash": "TPM2_ALG_SHA1",
         "pcrSelect": [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ],
       },
       { "hash": "TPM2_ALG_SHA256",
         "pcrSelect": [ 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 ]
       }
    ],
```

## COLOPHON
This page is part of release 4.1.3 of Open Source implementation of the TCG TPM2 Software Stack (TSS2). A description of the project, information about reporting bugs, and the latest version of this page can be found at https://github.com/tpm2-software/tpm2-tss/.


libuser.conf

package: libuser

title: libuser.conf(5)

text:
# libuser.conf(5)

## NAME
libuser.conf - configuration for libuser and libuser utilities

## FILE FORMAT
libuser.conf is a text file. Leading and trailing white space on each line is ignored. Lines starting with # are ignored.

The file defines variables grouped into sections. Each section starts with a section header:

[section name]

A single section header can appear more than once in the file. The lines following a section header define variables from that section:

variable = value

The value can be empty. A variable can have more than one value, specified by using more than one line defining that variable. All currently defined variables accept only the first value and ignore the others, if any.

## [defaults]
create_modules

A list of module names to use when creating user or group entries, unless the application specifies a different list. The module names in the list can be separated using space, tab or comma. Default value is files shadow.

crypt_style

The algorithm to use for password encryption when creating new passwords. The current algorithm may be retained when changing a password of an existing user, depending on the application. Possible values are des, md5, blowfish, sha256, sha512, and yescrypt, all case-insensitive. Unrecognized values are treated as des. Default value is des.

hash_rounds_min, hash_rounds_max

These variables specify an inclusive range of hash rounds used when crypt_style is sha256 or sha512. A number of hash rounds is chosen from this interval randomly. A larger number of rounds makes password checking, and brute-force attempts to guess the password by reversing the hash, more CPU-intensive. The number of rounds is restricted to the interval [1000, 999999999]. If only one of the above variables is specified, the number of rounds used is specified by the other variable. If neither variable is specified, the number of rounds is chosen by libc.

mailspooldir

The directory containing user's mail spool files. Default value is /var/mail.

moduledir

The directory containing libuser modules. Default value uses the modules installed with libuser, corresponding to the architecture of the libuser library, e.g. /usr/lib/libuser or /usr/lib64/libuser (assuming libuser was configured with --prefix=/usr).

modules

A list of module names to use when not creating user or group entries, unless the application specifies a different list. The module names in the list can be separated using space, tab or comma. Default value is files shadow.

skeleton

The directory containing files to copy to newly created home directories. Default value is /etc/skel.

## [import]
login_defs

A path to the login.defs file from shadow. If this variable is defined, the variables from the named file are used in place of some libuser variables. Variables explicitly defined in libuser.conf are not affected by contents of login.defs. The following variables are imported:

Variable

Imported as

ENCRYPT_METHOD

defaults/crypt_style

GID_MIN

groupdefaults/LU_GIDNUMBER

MAIL_DIR

defaults/mailspooldir

MD5_CRYPT_ENAB

defaults/crypt_style

PASS_MAX_DAYS

userdefaults/LU_SHADOWMAX

PASS_MIN_DAYS

userdefaults/LU_SHADOWMIN

PASS_WARN_AGE

userdefaults/LU_SHADOWWARNING

SHA_CRYPT_MIN_ROUNDS

defaults/hash_rounds_min

SHA_CRYPT_MAX_ROUNDS

defaults/hash_rounds_max

UID_MIN

userdefaults/LU_UIDNUMBER

The following variables are not imported: CREATE_HOME, GID_MAX, MAIL_FILE, SYSLOG_SG_ENAB, UID_MAX, UMASK, USERDEL_CMD, USERGROUPS_ENAB

default_useradd

A path to the default/useradd file from useradd in shadow. If this variable is defined, the variables from the named file are used in place of some libuser variables. Variables explicitly defined in libuser.conf are not affected by contents of default/useradd. The following variables are imported:

Variable

Imported as

EXPIRE

userdefaults/LU_SHADOWEXPIRE

GROUP

userdefaults/LU_GIDNUMBER

HOME

userdefaults/LU_HOMEDIRECTORY

INACTIVE

userdefaults/LU_SHADOWINACTIVE

SHELL

userdefaults/LU_LOGINSHELL

SKEL

defaults/skeleton

The HOME variable value has /%n appended to it before importing.

## [userdefaults]
This section defines attribute values of newly created user entities. There is one special variable:

LU_UIDNUMBER

A decimal number, the first allowed UID value for regular users (not system users). Default value is 500.

All other variables have the same names as the attribute names from <libuser/entity.h> and define attribute values. Either the macro name (e.g. LU_GECOS) or the macro content (e.g. pw_gecos) can be used; if both are used, the one appearing later in the configuration file is used.

The % character in the value of the variable introduces an escape sequence: %n is replaced by the user name, %d is replaced by current date in days since the epoch, %u is replaced by the user's UID. There is no way to escape the % character and avoid this substitution.

After the userdefaults section is processed, modules may define additional attributes or even override the attributes defined in this section.

## [groupdefaults]
The groupdefaults section is similar to userdefaults. There is one special variable:

LU_GIDNUMBER

A decimal number, the first allowed GID value for regular groups (not system groups). Default value is 500.

The other variables follow the same rules as in the userdefaults section, except that %n and %u are replaced by the group name and group's GID, respectively.

After the groupdefaults section is processed, modules may define additional attributes or even override the attributes defined in this section.

## [files]
Configures the files module, which manages /etc/group and /etc/passwd. The configuration variables are probably useful only for libuser development.

directory

The directory containing the group and passwd files. Default value is /etc.

nonroot

Allow module initialization when not invoked as the root user if the value is yes.

## [shadow]
Configures the files module, which manages /etc/gshadow and /etc/shadow. The configuration variables are probably useful only for libuser development.

directory

The directory containing the gshadow and shadow files. Default value is /etc.

nonroot

Allow module initialization when not invoked as the root user if the value is yes.

## [ldap]
Configures the ldap module, which manages an user database accessible using LDAP.

userBranch

The LDAP suffix for user entities. Default value is ou=People.

groupBranch

The LDAP suffix for group entities. Default value is ou=Group.

server

A domain name or an URI of the LDAP server. The URI can use the ldap, ldapi or the ldaps protocol. When a simple domain name is used, the connection fails if TLS can not be used; an URI using the ldap protocol allows connection without TLS. TLS is never used with the ldapi protocol. Default value is ldap.

basedn

The base DN of the server. Default value is dc=example,dc=com.

binddn

A DN for binding to the server. If the value is empty or binding using this DN fails, a DN of uid=user,userBranch,basedn is used, where userBranch and basedn are variables from this section and user is the user name of the invoking user, unless overridden by the user variable from this section. Default value is cn=manager,dc=example,dc=com.

user

The SASLv2 identity for authenticating to the LDAP server, also overrides the user name for generating a bind DN. Default value is the name of the invoking user.

password

The password used for a simple bind by default. If not specified, there is no default and the user must supply the password each time. IT IS STRONGLY RECOMMENDED NOT TO STORE A PASSWORD IN THE SYSTEM-WIDE /etc/libuser.conf FILE. The configuration file is world-readable by default, and setuid programs that prompt for a server name could be used to send the password to an attacker-controlled server.

authuser

The SASLv2 authorization user, if non-empty. Default value is empty.

bindtype

The list of bind types to use, separated by commas. Allowed bind types are simple, sasl, and sasl/mechanism, where mechanism is a SASL mechanism. The bind types (but not necessarily mechanism) are case-insensitive. If more than one bind type is specified, their relative order is ignored. Default value is simple,sasl.

## [sasl]
Configures the sasl module, which manages a SASLv2 user database.

appname

Name of the SASLv2 application. Default value is empty.

domain

Domain used by libuser for the SASLv2 authentication object. Default value is empty.

## BUGS
Invalid lines in the configuration file (or the imported shadow configuration files) are silently ignored.

## FILES
/etc/libuser.conf

The default location of the configuration file. Can be overridden by the LIBUSER_CONF environment variable, except in set-uid or set-gid programs.


xforms

package: libxforms

title: xforms(5)

summary: A GUI Toolkit for X Window Systems

text:
# xforms(5)

## NAME
xforms - A GUI Toolkit for X Window Systems

## SYNOPSIS
Forms Library for X (xforms) is a GUI toolkit and builder for the X Window Systems and runs on all major UNIX platforms as well as OpenVMS and OS2. Forms Library is too complex to be described in the "man" page format. Ask your system administrator for the location of the HTML, PDF or PostScript document or follow the links on the Forms Library's home page for an online version of the documentation.

## DESCRIPTION
Forms Library is a graphical user interface toolkit based on Xlib for X Window Systems. It comes with a rich set of objects such as buttons, browsers, sliders and menus integrated into an elegant event/object callback execution model that allows fast and easy construction of X applications. In addition, the library has support for image read and write, format conversion and simple image processing. The library consists of a flexible set of C-routines that can be used in C and C++ programs (As of this writing, perl, ada95, pascal, scheme and Fortran bindings to the Forms Library are in beta.)

The library is efficient and portable and runs on all major Unix platforms, including Sun, SGI, HP, DEC Alpha/OSF, IBM RS6000, Convex, Cray, Linux, FreeBSD, NetBSD, SCO, Unixware, OpenBSD , BSDi, DecSystem(mips)/Ultrix and others. Non-unix platforms include OpenVMS, OS/2, and Window/NT.

Bundled with the library is also a Form designer, fdesign, which can be used to build interaction forms in a WYSIWYG (what you see is what you get) way and to generate the corresponding C (or any of the binding languages) code for you. 50+ demos in source code are distributed with the library.

## OPTIONS
All programs written using the Forms Library recognize the following command line options

-display host:dpy

specifies the server to connect to.

-bw borderwidth

specifies the border width to use for built-in objects.

-flversion

prints the xforms version information.

-visual visualName

requests a visual by name such as TrueColor etc. By default the Forms Library always selects the visual that has the most depth.

-depth depth

requests a specific depth.

-fldebug level

generates some info about the state of the XForms. where level is an integer between 1-5 and controls the amount of information to output. Depending on the options used when the Forms Library was built, a level more than 3 might not be available.

-sync

runs the application in synchronous mode with debug level set to 4.

-private

requests a private colormap for the application.

-shared

requests a shared colormap even if the application needs more colors than available. For those colors that can't be allocated in the shared colormap, substitutions are made so the closest matching color is used.

-stdcmap

requests a standard colormap.

-name newname

specifies the application name under which resources are to be obtained, rather than the default executable file name.

## SEE ALSO
fdesign(1L), fd2ps(1L)

## AUTHOR
Copyright (c) 1996-2002 T.C. Zhao, Mark Overmars and Steve Lamont

Since 2002: GNU Lesser General Public License

Maintainers: Jean-Marc Lasgouttes, Angus Leeming, Jens Thoms Toerring <jt@toerring.de>

## HOME PAGE
http://xforms-toolkit.org

http://savannah.nongnu.org/projects/xforms/


lircd.conf

package: lirc

title: lircd.conf(5)

summary: lirc main configuration file

text:
# lircd.conf(5)

## NAME
lircd.conf - lirc main configuration file

## DESCRIPTION
The file has two purposes: to provide timing information to the driver so it can decode the data to button presses, and to provide a mapping from button presses to key symbols used by lircd(8).

The basic structure is a list of remote blocks. Whitespace and line breaks are used as delimiters.

If the comment character (#) appears as the first character on a line the rest of the line is ignored.

## REMOTE BLOCKS
Remote blocks are either normal or raw.

Normal remote blocks begin with begin remote and ends with end remote. The first part of the block describes the basic properties of the remote, see REMOTE DESCRIPTION SECTION. Following this is a codes section, which is delimited by begin codes and end codes.

Each line in a codes section contains the name of a button on the remote followed by a hexadecimal data value matching the data part of the IR frame (see REMOTE DESCRIPTION SECTION). You may not assign the same name to two buttons in the same remote section.

Raw remote blocks are identical to normal blocks besides the codes section which is a list of button descriptions enclosed by begin raw_codes and end raw_codes.

A raw button description begins with the parameter name followed by the name of the button. The button description ends with the next button description or the end of the raw_codes block. The lines in between is a list of decimal numbers describing the signal sent by that button. The first number indicates the duration of the first pulse in microseconds. The second number indicates the duration of the space which follows it. Pulse and space durations alternate for as long as is necessary. The last duration should represent a pulse.

## REMOTE DESCRIPTION SECTION
Each line in this section contains a parameter followed by the value or values that should be assigned to that parameter. Parameters are optional unless otherwise stated.

All values are decimal integers that are either dimensionless or have units of microseconds unless otherwise stated. Hexadecimal numbers should be prefixed by 0x. If the remote does not have a particular "feature," then the line may be omitted. The button code is sent just after the pre signal and just before the post signal.

Some parameters describe the bits in the IR protocol. The frame is normally defined like

|header|plead|pre data|pre|data|post|post data|ptrail|foot|gap|

where most parameters defaults to 0. Some parameters change the overall frame layout e. g., the repeat parameter.

include ”<path>”

Include the given path using normal include semantics. If the path is relative, it's interpreted relative to the main lircd.conf file. <path> must be enclosed in double quotes. It can contain a glob(3) pattern in which case all matching files are included.

manual_sort <1|0>

Normally, lircd tries to sort multiple remotes so the one which decodes fastest are used first. Setting manual_sort to 1 in any remote disables this and uses the remotes in the order they are listed in lircd.conf or as the alphanumerically sorted filenames in lircd.conf.d.

name <remote name>

The unique name assigned to the remote control (may not contain whitespace). Within a single file all names must be unique. Parameter is mandatory.

suppress_repeat <repeats>

Suppress a given number of repeats for all buttons in this remote. Defaults to 0, which means that no repeats are suppressed. Note that lircrc has a corresponding repeat parameter which can be used to suppress repeats for specific button/client combinations.

flags <flag1><|flag2>...

Flags are special text strings which describe various properties of the remote and determine the semantics of some of the following fields. Multiple flags should be separated by the pipe(|) symbol. See FLAGS.

driver <driver name>

For lirccode drivers which does not have timing information the optional driver attribute names the driver which is required to use this remote.

bits <number of data bits>

The number of data bits in the hexadecimal codes which describe each button (decimal integer).

eps <relative error tolerance>

The relative error tolerance for received signals in percent. By default, irrecord set this to 30 (i. e., 30%).

aeps <absolute error tolerance>

The absolute error tolerance for received signals (microseconds). The default is the hardcoded driver dependent resolution value. By default irrecord sets this to 100.

header <phead> <shead>

The initial pulse and space sent (microseconds).

three <pthree> <sthree>

Only used by RC-MM remotes

two <ptwo> <stwo>

Only used by RC-MM remotes

one <pone> <sone>

The pulse and space lengths representing a one.

zero <pzero> <szero>

The pulse and space lengths representing a zero.

ptrail <trailing pulse>

A trailing pulse, immediately following the post_data.

plead <leading pulse>

A leading pulse, immediately after the header.

foot <pfoot> <sfoot>

A pulse and space, immediately following the trailing pulse.

repeat <prepeat> <srepeat>

A pulse and space that replaces everything between leading pulse and the trailing pulse, whenever a signal is repeated. The foot is not sent, and the header is not sent unless the REPEAT_HEADER flag is present.

pre_data_bits <number of pre_data_bits>

The number of bits in the pre_data code.

pre_data <hexadecimal number>

Hexadecimal code indicating the sequence of ones and zeros immediately following the leading pulse.

post_data_bits <number of post data bits>

The number of bits in the post_data code.

post_data <hexadecimal number>

Hexadecimal code indicating the sequence of ones and zeros immediately following the post signal.

pre <ppre> <spre>

A pulse and space immediately following the pre_data.

post <ppost> <spost>

A pulse and space immediately following the button code.

gap <gap length>

A (typically long) space which follows the trailing pulse.

repeat_gap <repeat_gap length>

A gap immediately following the trailing pulse, and preceding a repetition of the same code that's due to a the same press of the button.

min_repeat <minimum number of repetitions>

The minimum times a signal is repeated when sent. Note that 0 means the signal is sent only once. Not used when receiving.

toggle_bit <bit to toggle>

A bit of the pre_data, code, or post_data that is toggled between one and zero each time a button is pressed. This parameter is obsoleted by toggle_bit_mask and should be used in new configs.

toggle_bit_mask <hexadecimal mask>

Bits which are toggled between one and zero each time a button is pressed. The mask is applied to the concatenated value of pre data - data - post_data.

repeat_mask <mask>

Mask defines which bits are inverted for repeats.

frequency <hertz>

Remote carrier frequency, defaults to 38000.

duty_cycle <on time>

The percentage of time during a pulse that infrared light is being sent. This is an integer between 1-100 inclusive. default is 50.

## FLAGS
Flags are values set in the flags parameter.

RC5

The remote uses the RC5 protocol.

RC6

The remote uses the RC6 protocol.

RCMM

The remote uses the RC-MM protocol.

SHIFT_ENC

Obsolete flag, now a synonym for RC5. The position of the pulse (before or after the space) determines whether the bit is a one or a zero.

SPACE_ENC

A one and a zero can be distinguished by the length of the spaces, used by the NEC protocol and others.

REVERSE

Reverses the bit order of the pre_data, the post_data and the codes (e.g., 0x123 becomes 0xC48). If this flag is present, the least significant bit is sent first.

NO_HEAD_REP

The header is not sent when a signal (the button is held down) is repeated even though there is no special repeat code.

NO_FOOT_REP

The foot is not sent when a signal is repeated (the button is held down) even though there is no special repeat code .

CONST_LENGTH

The total signal length is always constant. The gap length now represents the length of the entire signal, and the actual gap at the end of the signal is adjusted accordingly.

RAW_CODES

The codes are in raw format.

REPEAT_HEADER

Send the header when the signal is repeated even though the remote has a special repeat code.

## DISCLAIMER
LIRC was designed to collect IR data and save it in a private, compact, yet human readable format with the purpose of being able to re-transmit (or re-recognize) these signals. It was not designed with the goal of providing a well documented and tested configuration file format that could be used e.g., to generate arbitrary IR signals or to convert them to other formats. The configuration file should thus not be considered a public interface to LIRC.

This manpage should be understood with this in mind. It was authored by reading the code of LIRC, and does not constitute an authoritative specification of the behavior of LIRC and its configuration file. Also, some less commonly used flags and parameters are not documented.

## SEE ALSO
lircd(8)

irrecord(1)

http://en.wikipedia.org/wiki/RC-5

http://www.sbprojects.com/knowledge/ir/


lircrc

title: lircrc(5)

text:
# lircrc(5)

## NAME
lircrc - application-specific remotes signals configuration

## DESCRIPTION
lircrc is the last LIRC configuration point in the flow of events from the kernel to the application. It provides a way to translate the application-agnostic events which lircd makes available on /var/run/lirc/lircd to application-specific strings. The translation is invoked by LIRC-aware applications by using the the lirc_code2char() routine in the lirc_client library.

The lircrc event mapping is not only mapping from a remote event to an application string. It also supports a variety of functionality such as repeat suppression, modes, long keypresses and button sequences.

The default location for lircrc is ~/.config/lircrc with a global fallback in /etc/lirc/lircrc. Many applications which uses the lircrc translations have private locations for the file.

The programmatic interface to the lircrc functionality is described in the Client API manual, see below

The file format is described in the configuration manual, see below.

## SEE ALSO
http://lirc.org/html/configure.html#lircrc_format

Description of the lircrc file format.

http://lirc.org/html/lirc_client.html

Client API, the programmatic interface to the lircrc files.


mfschunkserver.cfg

package: lizardfs-chunkserver

title: mfschunkserver.cfg(5)

text:
# mfschunkserver.cfg(5)

## NAME
mfschunkserver.cfg - main configuration file for *mfschunkserver*

## DESCRIPTION
The file mfschunkserver.cfg contains configuration of LizardFS chunkserver process.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored.

## OPTIONS
Configuration options:

DATA_PATH

where to store files with usage statistics and daemon lock file

LABEL

the label of this chunkserver (for tiering)

WORKING_USER

user to run daemon as

WORKING_GROUP

group to run daemon as (optional - if empty then default user group will be used)

SYSLOG_IDENT

name of process to place in syslog messages (default is mfschunkserver)

LOCK_MEMORY

whether to perform mlockall() to avoid swapping out mfschunkserver process (default is 0, i.e. no)

NICE_LEVEL

nice level to run daemon with (default is -19 if possible; note: process must be started as root to increase priority)

MASTER_HOST

address of LizardFS master host to connect with (default is mfsmaster)

MASTER_PORT

number of LizardFS master port to connect with (default is 9420)

MASTER_RECONNECTION_DELAY

delay in seconds before trying to reconnect to the master server after disconnection (default is 5)

MASTER_TIMEOUT

timeout (in seconds) for the master server connection (default is 60, minimum is 0.01)

BIND_HOST

local address to use for connecting with the master server (default is *, i.e. default local address)

CSSERV_LISTEN_HOST

IP address to listen on for client (mount) connections (* means any)

CSSERV_LISTEN_PORT

port to listen on for client (mount) connections (default is 9422)

CSSERV_TIMEOUT

timeout (in seconds) for client (mount) connections (default is 5)

HDD_CONF_FILENAME

alternative name of mfshdd.cfg file

HDD_LEAVE_SPACE_DEFAULT

free space threshold to set volume as 100% utilized when there is less than given amount of free space left (default is "4GiB"). This number is always added to the used disk space reported by chunkserver.

HDD_TEST_FREQ

chunk test period in seconds (default is 10)

HDD_ADVISE_NO_CACHE

whether to remove each chunk from page when closing it to reduce cache pressure generated by chunkserver (default is 0, i.e. no)

HDD_PUNCH_HOLES

if enabled then chunkserver detects zero values in chunk data and frees corresponding file blocks (decreasing file system usage). This option works only on Linux with file systems supporting punching holes (XFS, ext4, Btrfs, tmpfs)

ENABLE_LOAD_FACTOR

if enabled, chunkserver will send periodical reports of its I/O load to master, which will be taken into consideration when picking chunkservers for I/O operations.

REPLICATION_BANDWIDTH_LIMIT_KBPS

limit how many kilobytes can be replicated from other chunkservers to this chunkserver in every second (by default undefined, i.e. no limits)

NR_OF_NETWORK_WORKERS

number of threads which handle (in a round-robin manner) connections with clients (default is 1); these threads are responsible for reading from sockets and coping data from internal buffers to sockets

NR_OF_HDD_WORKERS_PER_NETWORK_WORKER

number of threads that each network worker may use to do disk operations like opening chunks, reading or writing them (default is 2)

READ_AHEAD_KB

additional number of kilobytes which should be passed to posix_fadvise(POSIX_FADV_WILLNEED) before reading data from a chunk (default is 0, i.e. use posix_fadvise only with the amount of data that is really needed; the value is aligned down to 64 KiB)

MAX_READ_BEHIND_KB

try to fix out-of-order read requests; the value tells how much of skipped data to read if an offset of some read operation is greater than the offset where the previos operation finished (default is 0, i.e. don’t read any skipped data; the value is aligned down to 64 KiB)

CREATE_NEW_CHUNKS_IN_MOOSEFS_FORMAT

whether to create new chunks in the MooseFS format (signature + <checksum>* + <data block>*) or in the newer interleaved format ([<checksum> <data block>]*). (Default is 1, i.e. new chunks are created in MooseFS format)

PERFORM_FSYNC

call fsync() after a chunk is modified (default is 1, i.e. enabled)

REPLICATION_TOTAL_TIMEOUT_MS

total timeout for single replication operation. Replications that take longer than that are considered failed and are immediately aborted (default: 60000)

REPLICATION_CONNECTION_TIMEOUT_MS

connection for single replication operation. If connecting to another chunkserver takes longer than this timeout, the operation is considered failed and is immediately aborted (default: 1000)

REPLICATION_WAVE_TIMEOUT_MS, ADVANCED

timeout for single wave in replication. After this timeout, next wave of read requests is sent to other chunkservers (default: 500)

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfschunkserver(8), mfshdd.cfg(5)


mfshdd.cfg

title: mfshdd.cfg(5)

text:
# mfshdd.cfg(5)

## NAME
mfshdd.cfg - list of LizardFS storage directories for mfschunkserver

## DESCRIPTION
The file mfshdd.cfg contains list of directories (mountpoints) used for LizardFS storage (one per line). Directory prefixed by * character causes given directory to be freed by replicating all data already stored there to another locations. Lines starting with # character are ignored.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfschunkserver(8), mfschunkserver.cfg(5)


iolimits.cfg

package: lizardfs-client

title: iolimits.cfg(5)

summary: local I/O limiting configuration

text:
# iolimits.cfg(5)

## NAME
iolimits.cfg - local I/O limiting configuration

## DESCRIPTION
The file iolimits.cfg contains configuration of the local I/O limiter.

## SYNTAX, OPTIONS
The same as in globaliolimits.cfg(5).

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmount.cfg(5), globaliolimits.cfg(5)


mfsmount.cfg

title: mfsmount.cfg(5)

text:
# mfsmount.cfg(5)

## NAME
mfsmount.cfg - configuration file for the mfsmount command

## SYNTAX
OPTION,OPTION,OPTION,...

OPTION

PATH

The # character starts comments.

## DESCRIPTION
The mfsmount.cfg file defines the default mountpoint and the default mfsmount specific mount options for the mfsmount command. Options can be either stated in one line as a comma separated list of options, or by giving one option per line. Options not mfsmount specific will be ignored.

The default mount point should be listed on a separate line, giving the full path. Lines starting with the # character are ignored.

### EXAMPLES

```
#
# Default Options
#
mfsmaster=192.168.1.1
mfspassword=changeme
#
# Default mount point
#
/mnt/lizardfs
```

### REPORTING BUGS
Report bugs to <contact@lizardfs.org>.

### COPYRIGHT
Copyright 2016-2019 Skytechnology Sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmount(1) lizardfs(7)


globaliolimits.cfg

package: lizardfs-master

title: globaliolimits.cfg(5)

summary: global I/O limiting configuration

text:
# globaliolimits.cfg(5)

## NAME
globaliolimits.cfg - global I/O limiting configuration

## DESCRIPTION
The file globaliolimits.cfg contains configuration of the global I/O limiter.

## SYNTAX
Syntax is:

option value

Lines starting with # character are ignored.

## OPTIONS
Configuration options:

subsystem <subsystem>

The cgroups subsystem by which clients are classified. If left unspecified, all clients are considered unclassified (see below).

limit unclassified <throughput in KiB/s>

This is a special entry for clients that don’t match any group specified in configuration file or for all clients if subsystem is unspecified. If this entry is unspecified and subsystem is unspecified as well, I/O limiting is disabled entirely. If this entry is unspecified but subsystem is specified, unclassified clients are not allowed to perform I/O.

limit <group> <throughput in KiB/s>

Set limit for clients belonging to the cgroups group <group>. In LizardFS, subgroups of <group> constitute independent groups; they are not allowed to use <group>'s bandwidth reservation and they don’t count against <group>'s usage.

## EXAMPLES

```
# empty file
```

I/O limiting is disabled, no limits are enforced.

```
limit unclassified 1024
```

All clients are unclassified and share 1MiB/s of bandwidth.

```
subsystem blkio
limit /a 1024
```

Clients in the blkio /a group are limited to 1MiB/s, no other clients can perform any I/O.

```
subsystem blkio
limit unclassified 256
limit /a   1024
limit /b/a 2048
```

The blkio group /a is allowed to transfer 1MiB/s, while /b/a gets 2MiB/s. Clients from other groups (e.g. /b, /z, /a/a, /b/z) are considered unclassified and share 256KiB/s of bandwidth.

## TUNING NOTES
Global I/O limiting is managed by the master server. Mount instances reserve bandwidth allocations from master when they want to perform I/O to chunkservers.

To avoid overloading the master under heavy traffic, mounts try to predict their future usage and reserve at once all the bandwidth they will for the next renegotiation period (see mfsmaster.cfg(5)).

Such reservation are wasted if the traffic at given mount instance suddenly drops.

The ratio of bandwidth being wasted due to this phenomenon shouldn’t exceed fsp/b, where:

```
f is the frequency of sudden traffic drops in the whole installation (in 1/s)
s is the average size of such drop (in KiB/s)
p is the renegotiation period (in s)
b is the bandwidth limit (in KiB/s)
```

This applies to each group separately, because groups reserve their bandwidth independently from each other.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LizardFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster.cfg(5)