Config-Model-Systemd

 view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

      'Group' => "Set the UNIX user or group that the processes are executed as, respectively. Takes a single
user or group name, or a numeric ID as argument. For system services (services run by the system service
manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
systemd --user), the default is C<root>, but C<User> may be
used to specify a different user. For user services of any other user, switching user identity is not
permitted, hence the only valid setting is the same user the user's service manager is running as. If no group
is set, the default group of the user is used. This setting does not affect commands whose command line is
prefixed with C<+>.

Note that this enforces only weak restrictions on the user/group name syntax, but will generate
warnings in many cases where user/group names do not adhere to the following rules: the specified
name should consist only of the characters a-z, A-Z, 0-9, C<_> and
C<->, except for the first character which must be one of a-z, A-Z and
C<_> (i.e. digits and C<-> are not permitted as first character). The
user/group name must have at least one character, and at most 31. These restrictions are made in
order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux
systems. For further details on the names accepted and the names warned about see L<User/Group Name
Syntax|https://systemd.io/USER_NAMES>.

When used in conjunction with C<DynamicUser> the user/group name specified is
dynamically allocated at the time the service is started, and released at the time the service is
stopped \x{2014} unless it is already allocated statically (see below). If C<DynamicUser>
is not used the specified user and group must have been created statically in the user database no
later than the moment the service is started, for example using the
L<sysusers.d(5)>
facility, which is applied at boot or package install time. If the user does not exist by then
program invocation will fail.

If the C<User> setting is used the supplementary group list is initialized
from the specified user's default group list, as defined in the system's user and group
database. Additional groups may be configured through the C<SupplementaryGroups>
setting (see below).",
      'IOSchedulingClass' => 'Sets the I/O scheduling class for executed processes. Takes one of the strings
C<realtime>, C<best-effort> or C<idle>. The kernel\'s
default scheduling class is C<best-effort> at a priority of 4. If the empty string is
assigned to this option, all prior assignments to both C<IOSchedulingClass> and
C<IOSchedulingPriority> have no effect. See
L<ioprio_set(2)> for
details.',
      'IOSchedulingPriority' => 'Sets the I/O scheduling priority for executed processes. Takes an integer between 0
(highest priority) and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O
bandwidth is made available to the unit\'s processes, larger values mean less bandwidth. The available
priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned
to this option, all prior assignments to both C<IOSchedulingClass> and
C<IOSchedulingPriority> have no effect. For the kernel\'s default scheduling class
(C<best-effort>) this defaults to 4. See
L<ioprio_set(2)> for
details.',
      'IPCNamespacePath' => 'Takes an absolute file system path referring to a Linux IPC namespace
pseudo-file (i.e. a file like C</proc/$PID/ns/ipc> or a bind mount or symlink to
one). When set the invoked processes are added to the network namespace referenced by that path. The
path has to point to a valid namespace file at the moment the processes are forked off. If this
option is used C<PrivateIPC> has no effect. If this option is used together with
C<JoinsNamespaceOf> then it only has an effect if this unit is started before any of
the listed units that have C<PrivateIPC> or
C<IPCNamespacePath> configured, as otherwise the network namespace of those
units is reused.',
      'IgnoreSIGPIPE' => 'Takes a boolean argument. If true, C<SIGPIPE> is ignored in the
executed process. Defaults to true since C<SIGPIPE> is generally only useful in
shell pipelines.',
      'ImportCredential' => "Pass one or more credentials to the unit. Takes a credential name for which we will
attempt to find a credential that the service manager itself received under the specified name \x{2014}
which may be used to propagate credentials from an invoking environment (e.g. a container manager
that invoked the service manager) into a service. If the credential name is a glob, all credentials
matching the glob are passed to the unit. Matching credentials are searched for in the system
credentials, the encrypted system credentials, and under C</etc/credstore/>,
C</run/credstore/>, C</usr/lib/credstore/>,
C</run/credstore.encrypted/>, C</etc/credstore.encrypted/>, and
C</usr/lib/credstore.encrypted/> in that order. When multiple credentials of the
same name are found, the first one found is used.

The globbing expression implements a restrictive subset of L<glob(7)>: only
a single trailing C<*> wildcard may be specified. Both C<?> and
C<[]> wildcards are not permitted, nor are C<*> wildcards anywhere
except at the end of the glob expression.

Optionally, the credential name or glob may be followed by a colon followed by a rename pattern.
If specified, all credentials matching the credential name or glob are renamed according to the given
pattern. For example, if C<ImportCredential=my.original.cred:my.renamed.cred> is
specified, the service manager will read the C<my.original.cred> credential and make
it available as the C<my.renamed.cred> credential to the service. Similarly, if
C<ImportCredential=my.original.*:my.renamed.> is specified, the service manager will
read all credentials starting with C<my.original.> and make them available as
C<my.renamed.xxx> to the service.

If C<ImportCredential> is specified multiple times and multiple credentials
end up with the same name after renaming, the first one is kept and later ones are dropped.

When multiple credentials of the same name are found, credentials found by
C<LoadCredential> and C<LoadCredentialEncrypted> take priority over
credentials found by C<ImportCredential>.

Note that if decryption or authentication of a credential picked up as result of
C<ImportCredential> fails it will be skipped gracefully (a warning is generated, but
the credential will not be made available to the invoked service). This is different for those
configured via
C<SetCredentialEncrypted>/C<LoadCredentialEncrypted>, where failed
decryption/authentication will result in service failure.",
      'InaccessiblePaths' => '*ExecPaths',
      'KeyringMode' => 'Controls how the kernel session keyring is set up for the service (see L<session-keyring(7)> for
details on the session keyring). Takes one of C<inherit>, C<private>,
C<shared>. If set to C<inherit> no special keyring setup is done, and the kernel\'s
default behaviour is applied. If C<private> is used a new session keyring is allocated when a
service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for
system services, as this ensures that multiple services running under the same system user ID (in particular
the root user) do not share their key material among each other. If C<shared> is used a new
session keyring is allocated as for C<private>, but the user keyring of the user configured with
C<User> is linked into it, so that keys assigned to the user may be requested by the unit\'s
processes. In this mode multiple units running processes under the same user ID may share key material. Unless
C<inherit> is selected the unique invocation ID for the unit (see below) is added as a protected
key by the name C<invocation_id> to the newly created session keyring. Defaults to
C<private> for services of the system service manager and to C<inherit> for
non-service units and for services of the user service manager.',
      'LimitAS' => "Set soft and hard limits on various resources for executed processes. See
L<setrlimit(2)> for
details on the process resource limit concept. Process resource limits may be specified in two formats:
either as single value to set a specific soft and hard limit to the same value, or as colon-separated
pair C<soft:hard> to set both limits individually
(e.g. C<LimitAS=4G:16G>).  Use the string C<infinity> to configure no
limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may
be used for resource limits measured in bytes (e.g. C<LimitAS=16G>). For the limits
referring to time values, the usual time units ms, s, min, h and so on may be used (see
L<systemd.time(7)> for
details). Note that if no time unit is specified for C<LimitCPU> the default unit of
seconds is implied, while for C<LimitRTTIME> the default unit of microseconds is
implied. Also, note that the effective granularity of the limits might influence their
enforcement. For example, time limits specified for C<LimitCPU> will be rounded up
implicitly to multiples of 1s. For C<LimitNICE> the value may be specified in two
syntaxes: if prefixed with C<+> or C<->, the value is understood as
regular Linux nice value in the range -20\x{2026}19. If not prefixed like this the value is understood as
raw resource limit parameter in the range 0\x{2026}40 (with 0 being equivalent to 1).

Note that most process resource limits configured with these options are per-process, and
processes may fork in order to acquire a new set of resources that are accounted independently of the
original process, and may thus escape limits set. Also note that C<LimitRSS> is not
implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
controls listed in
L<systemd.resource-control(5)>
over these per-process limits, as they apply to services as a whole, may be altered dynamically at
runtime, and are generally more expressive. For example, C<MemoryMax> is a more
powerful (and working) replacement for C<LimitRSS>.

Note that C<LimitNPROC> will limit the number of processes from one (real) UID and
not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
processes running under the same UID. Please also note that the C<LimitNPROC> will not be
enforced if the service is running as root (and not dropping privileges). Due to these limitations,
C<TasksMax> (see L<systemd.resource-control(5)>) is typically a better choice than C<LimitNPROC>.

Resource limits not configured explicitly for a unit default to the value configured in the various
C<DefaultLimitCPU>, C<DefaultLimitFSIZE>, \x{2026} options available in
L<systemd-system.conf(5)>, and \x{2013}
if not configured there \x{2013} the kernel or per-user defaults, as defined by the OS (the latter only for user
services, see below).

For system units these resource limits may be chosen freely. When these settings are configured
in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
used to raise the limits above those set for the user manager itself when it was first invoked, as
the user's service manager generally lacks the privileges to do so. In user context these
configuration options are hence only useful to lower the limits passed in or to raise the soft limit
to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
available configuration mechanisms differ between operating systems, but typically require
privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
setting limits on the system service encapsulating the user's service manager, i.e. the user's
instance of C<user\@.service>. After making such changes, make sure to restart the
user's service manager.",
      'LimitCORE' => '*LimitAS',
      'LimitCPU' => '*LimitAS',
      'LimitDATA' => '*LimitAS',
      'LimitFSIZE' => '*LimitAS',
      'LimitLOCKS' => '*LimitAS',
      'LimitMEMLOCK' => '*LimitAS',
      'LimitMSGQUEUE' => '*LimitAS',
      'LimitNICE' => '*LimitAS',
      'LimitNOFILE' => '*LimitAS',
      'LimitNPROC' => '*LimitAS',
      'LimitRSS' => '*LimitAS',
      'LimitRTPRIO' => '*LimitAS',
      'LimitRTTIME' => '*LimitAS',
      'LimitSIGPENDING' => '*LimitAS',
      'LimitSTACK' => '*LimitAS',
      'LoadCredential' => "Pass a credential to the unit. Credentials are limited-size binary or textual objects
that may be passed to unit processes. They are primarily intended for passing cryptographic keys
(both public and private) or certificates, user account information or identity information from host
to services, but can be freely used to pass any kind of limited-size information to a service. The
data is accessible from the unit's processes via the file system, at a read-only location that (if
possible and permitted) is backed by non-swappable memory. The data is only accessible to the user
associated with the unit, via the C<User>/C<DynamicUser> settings
(as well as the superuser). When available, the location of credentials is exported as the
C<\$CREDENTIALS_DIRECTORY> environment variable to the unit's processes.

The C<LoadCredential> setting takes a textual ID to use as name for a
credential plus a file system path, separated by a colon. The ID must be a short ASCII string
suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path
is absolute it is opened as regular file and the credential data is read from it. If the absolute
path refers to an C<AF_UNIX> stream socket in the file system a connection is made
to it (once at process invocation) and the credential data read from the connection, providing an
easy IPC integration point for dynamically transferring credentials from other services.

If the specified path is not absolute and itself qualifies as valid credential identifier it is
attempted to find a credential that the service manager itself received under the specified name \x{2014}
which may be used to propagate credentials from an invoking environment (e.g. a container manager
that invoked the service manager) into a service. If no matching passed credential is found, the
system service manager will search the directories C</etc/credstore/>,
C</run/credstore/> and C</usr/lib/credstore/> for files under the
credential's name \x{2014} which hence are recommended locations for credential data on disk. If
C<LoadCredentialEncrypted> is used C</run/credstore.encrypted/>,
C</etc/credstore.encrypted/>, and
C</usr/lib/credstore.encrypted/> are searched as well. The per-user service manager
will search C<\$XDG_CONFIG_HOME/credstore/>,
C<\$XDG_RUNTIME_DIR/credstore/>, C<\$HOME/.local/lib/credstore/>
(and the counterparts ending with C<\x{2026}/credstore.encrypted/>) instead. The
L<systemd-path(1)> tool
may be used to query the precise credential store search path.

If the file system path is omitted it is chosen identical to the credential name, i.e. this is
a terse way to declare credentials to inherit from the service manager or credstore directories into
a service. This option may be used multiple times, each time defining an additional credential to
pass to the unit.

Note that if the path is not specified or a valid credential identifier is given, i.e.
in the above two cases, a missing credential is not considered fatal.

If an absolute path referring to a directory is specified, every file in that directory
(recursively) will be loaded as a separate credential. The ID for each credential will be the
provided ID suffixed with C<_\$FILENAME> (e.g., C<Key_file1>). When
loading from a directory, symlinks will be ignored.

The contents of the file/socket may be arbitrary binary or textual data, including newline
characters and C<NUL> bytes.

The C<LoadCredentialEncrypted> setting is identical to
C<LoadCredential>, except that the credential data is decrypted and authenticated
before being passed on to the executed processes. Specifically, the referenced path should refer to a
file or socket with an encrypted credential, as implemented by
L<systemd-creds(1)>. This
credential is loaded, decrypted, authenticated and then passed to the application in plaintext form,
in the same way a regular credential specified via C<LoadCredential> would be. A
credential configured this way may be symmetrically encrypted/authenticated with a secret key derived
from the system's TPM2 security chip, or with a secret key stored in
C</var/lib/systemd/credential.secret>, or with both. Using encrypted and
authenticated credentials improves security as credentials are not stored in plaintext and only
authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover,
credentials may be bound to the local hardware and installations, so that they cannot easily be
analyzed offline, or be generated externally. See
L<systemd.resource-control(5)>
for the details about C<DevicePolicy> or C<DeviceAllow>.

Note that encrypted credentials targeted for services of the per-user service manager must be
encrypted with systemd-creds encrypt --user, and those for the system service
manager without the C<--user> switch. Encrypted credentials are always targeted to a
specific user or the system as a whole, and it is ensured that per-user service managers cannot
decrypt secrets intended for the system or for other users.

The credential files/IPC sockets must be accessible to the service manager, but do not have to
be directly accessible to the unit's processes: the credential data is read and copied into separate,
read-only copies for the unit that are accessible to appropriately privileged processes. This is
particularly useful in combination with C<DynamicUser> as this way privileged data
can be made available to processes running under a dynamic UID (i.e. not a previously known one)
without having to open up access to all users.

In order to reference the path a credential may be read from within a
C<ExecStart> command line use C<\${CREDENTIALS_DIRECTORY}/mycred>,
e.g. C<ExecStart=cat \${CREDENTIALS_DIRECTORY}/mycred>. In order to reference the path
a credential may be read from within a C<Environment> line use
C<%d/mycred>, e.g. C<Environment=MYCREDPATH=%d/mycred>. For system
services the path may also be referenced as
C</run/credentials/UNITNAME> in cases where no
interpolation is possible, e.g. configuration files of software that does not yet support credentials
natively. C<\$CREDENTIALS_DIRECTORY> is considered the primary interface to look for
credentials, though, since it also works for user services.

Currently, an accumulated credential size limit of 1 MB per unit is enforced.

The service manager itself may receive system credentials that can be propagated to services
from a hosting container manager or VM hypervisor. See the L<Container
Interface|https://systemd.io/CONTAINER_INTERFACE> documentation for details
about the former. For the latter, pass L<DMI/SMBIOS|https://www.dmtf.org/standards/smbios> OEM string table entries
(field type
11) with a prefix of C<io.systemd.credential:> or
C<io.systemd.credential.binary:>. In both cases a key/value pair separated by
C<=> is expected. In the latter case, the right-hand side is Base64 decoded when
parsed (thus permitting binary data to be passed in). Example
L<qemu|https://www.qemu.org/docs/master/system/index.html> switch: C<-smbios
type=11,value=io.systemd.credential:xx=yy>, or C<-smbios
type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=>. Alternatively,
use the qemu C<fw_cfg> node
C<opt/io.systemd.credentials/>. Example qemu switch:
C<-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret>. They may also
be passed from the UEFI firmware environment via
L<systemd-stub(7)>,
from the initrd (see
L<systemd(1)>), or be
specified on the kernel command line using the C<systemd.set_credential=> and
C<systemd.set_credential_binary=> switches (see
L<systemd(1)> \x{2013} this is
not recommended since unprivileged userspace can read the kernel command line).

If referencing an C<AF_UNIX> stream socket to connect to, the connection will
originate from an abstract namespace socket, that includes information about the unit and the
credential ID in its socket name. Use L<getpeername(2)>
to query this information. The returned socket name is formatted as C<NUL>RANDOM C</unit/> UNITC</> ID, i.e. a C<NUL>
byte (as required
for abstract namespace socket names), followed by a random string (consisting of alphadecimal
characters), followed by the literal string C</unit/>, followed by the requesting
unit name, followed by the literal character C</>, followed by the textual credential
ID requested. Example: C<\\0adf9d86b6eda275e/unit/foobar.service/credx> in case the
credential C<credx> is requested for a unit C<foobar.service>. This
functionality is useful for using a single listening socket to serve credentials to multiple
consumers.

For further information see L<System and Service
Credentials|https://systemd.io/CREDENTIALS> documentation.",
      'LoadCredentialEncrypted' => '*LoadCredential',
      'LockPersonality' => 'Takes a boolean argument. If set, locks down the L<personality(2)> system
call so that the kernel execution domain may not be changed from the default or the personality selected with
C<Personality> directive. This may be useful to improve security, because odd personality
emulations may be poorly tested and source of vulnerabilities.',
      'LogExtraFields' => 'Configures additional log metadata fields to include in all log records generated by
processes associated with this unit, including systemd. This setting takes one or more journal field
assignments in the format C<FIELD=VALUE> separated by whitespace. See
L<systemd.journal-fields(7)>
for details on the journal field concept. Even though the underlying journal implementation permits
binary field values, this setting accepts only valid UTF-8 values. To include space characters in a
journal field value, enclose the assignment in double quotes (").
The usual specifiers are expanded in all assignments (see below). Note that this setting is not only
useful for attaching additional metadata to log records of a unit, but given that all fields and
values are indexed may also be used to implement cross-unit log record matching. Assign an empty
string to reset the list.

Note that this functionality is currently only available in system services, not in per-user
services.',
      'LogFilterPatterns' => 'Define an extended regular expression to filter log messages based on the
C<MESSAGE> field of the structured message. If the first character of the pattern is
C<~>, log entries matching the pattern should be discarded. This option takes a single
pattern as an argument but can be used multiple times to create a list of allowed and denied patterns.
If the empty string is assigned, the filter is reset, and all prior assignments will have no effect.

Because the C<~> character is used to define denied patterns, it must be replaced
with C<\\x7e> to allow a message starting with C<~>. For example,
C<~foobar> would add a pattern matching C<foobar> to the deny list, while
C<\\x7efoobar> would add a pattern matching C<~foobar> to the allow list.

Log messages are tested against denied patterns (if any), then against allowed patterns
(if any). If a log message matches any of the denied patterns, it is discarded immediately without considering
allowed patterns. Remaining log messages are tested against allowed patterns. Messages matching
against none of the allowed pattern are discarded. If no allowed patterns are defined, then all
messages are processed directly after going through denied filters.

Filtering is based on the unit for which C<LogFilterPatterns> is defined, meaning log
messages coming from
L<systemd(1)> about the
unit are not taken into account. Filtered log messages will not be forwarded to traditional syslog daemons,
the kernel log buffer (kmsg), the systemd console, or sent as wall messages to all logged-in
users.

Note that this functionality is currently only available in system services, not in per-user
services.',
      'LogLevelMax' => 'Sets the maximum log level for log messages generated by this unit. Takes a
syslog log level, one of C<emerg> (lowest log level, only highest
priority messages), C<alert>, C<crit>, C<err>,
C<warning>, C<notice>, C<info>, C<debug>
(highest log level, also lowest priority messages). See L<syslog(3)> for
details. By default, the maximum log level is not overridden.

This option can be used to configure the logging system to drop log messages of a specific
service above the specified level. For example, set
C<LogLevelMax>=C<info> in order to turn off debug logging of a
particularly chatty unit. Alternatively, this option can be used to enable extra logging about a

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

policy extensions and dependencies are in effect when C<RootMStack> is used as are
if C<RootImage> is used.',
      'RootVerity' => 'Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks
using dm-verity, if C<RootImage> is used and a root-hash is passed and if the used image itself
does not contain the integrity data. The integrity data must be matched by the root hash. If this option is not
specified, but a file with the C<.verity> suffix is found next to the image file, bearing otherwise
the same name (except if the image has the C<.raw> suffix, in which case the verity data file must
not have it in its name), the verity data is read from it and automatically used.

This option is supported only for disk images that contain a single file system, without an
enveloping partition table. Images that contain a GPT partition table should instead include both
root file system and matching Verity data in the same image, implementing the
L<Discoverable Partitions
Specification|https://uapi-group.org/specifications/specs/discoverable_partitions_specification>.',
      'RuntimeDirectory' => '*CacheDirectory',
      'RuntimeDirectoryMode' => '*CacheDirectoryMode',
      'RuntimeDirectoryPreserve' => 'Takes a boolean argument or C<restart>. If set to C<no> (the
default), the directories specified in C<RuntimeDirectory> are always removed when the service
stops. If set to C<restart> the directories are preserved when the service is both automatically
and manually restarted. Here, the automatic restart means the operation specified in
C<Restart>, and manual restart means the one triggered by systemctl restart
foo.service. If set to C<yes>, then the directories are not removed when the service is
stopped. Note that since the runtime directory C</run/> is a mount point of
C<tmpfs>, then for system services the directories specified in
C<RuntimeDirectory> are removed when the system is rebooted.

If C<DynamicUser> is used together with
C<RuntimeDirectoryPreserve> set to values other than C<no>, the logic
is slightly altered: the C<RuntimeDirectory> directories are created below
C</run/private/>, which is a host directory made inaccessible to unprivileged
users, which ensures that access to these directories cannot be gained through dynamic user ID
recycling. Symbolic links are created to hide this difference in behaviour. Both from the
perspective of the host and from inside the unit, the relevant directories hence always appear
directly below C</run/>.',
      'SELinuxContext' => 'Set the SELinux security context of the executed process. If set, this will override the
automated domain transition. However, the policy still needs to authorize the transition. This directive is
ignored if SELinux is disabled. If prefixed by C<->, failing to set the SELinux
security context will be ignored, but it is still possible that the subsequent
execve() may fail if the policy does not allow the transition for the
non-overridden context. This does not affect commands prefixed with C<+>. See
L<setexeccon(3)>
for details.',
      'SecureBits' => 'Controls the secure bits set for the executed process. Takes a space-separated combination of
options from the following list: C<keep-caps>, C<keep-caps-locked>,
C<no-setuid-fixup>, C<no-setuid-fixup-locked>, C<noroot>, and
C<noroot-locked>. This option may appear more than once, in which case the secure bits are
ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands
prefixed with C<+>. See L<capabilities(7)> for
details.',
      'SetCredential' => 'The C<SetCredential> setting is similar to
C<LoadCredential> but accepts a literal value to use as data for the credential,
instead of a file system path to read the data from. Do not use this option for data that is supposed
to be secret, as it is accessible to unprivileged processes via IPC. It\'s only safe to use this for
user IDs, public key material and similar non-sensitive data. For everything else use
C<LoadCredential>. In order to embed binary data into the credential data use
C-style escaping (i.e. C<\\n> to embed a newline, or C<\\x00> to embed
a C<NUL> byte).

The C<SetCredentialEncrypted> setting is identical to
C<SetCredential> but expects an encrypted credential in literal form as value. This
allows embedding confidential credentials securely directly in unit files. Use
L<systemd-creds(1)>\'
C<-p> switch to generate suitable C<SetCredentialEncrypted> lines
directly from plaintext credentials. For further details see
C<LoadCredentialEncrypted> above.

When multiple credentials of the same name are found, credentials found by
C<LoadCredential>, C<LoadCredentialEncrypted> and
C<ImportCredential> take priority over credentials found by
C<SetCredential>. As such, C<SetCredential> will act as default if
no credentials are found by any of the former. In this case, not being able to retrieve the credential
from the path specified in C<LoadCredential> or
C<LoadCredentialEncrypted> is not considered fatal.',
      'SetCredentialEncrypted' => '*SetCredential',
      'SetLoginEnvironment' => 'Takes a boolean parameter that controls whether to set the C<$HOME>,
C<$LOGNAME>, and C<$SHELL> environment variables. If not set, this
defaults to true if C<User>, C<DynamicUser> or
C<PAMName> are set, false otherwise. If set to true, the variables will always be
set for system services, i.e. even when the default user C<root> is used. If set to
false, the mentioned variables are not set by the service manager, no matter whether
C<User>, C<DynamicUser>, or C<PAMName> are used or
not. This option normally has no effect on services of the per-user service manager, since in that
case these variables are typically inherited from user manager\'s own environment anyway.',
      'SmackProcessLabel' => 'Takes a C<SMACK64> security label as argument. The process executed by the unit
will be started under this label and SMACK will decide whether the process is allowed to run or not, based on
it. The process will continue to run under the label specified here unless the executable has its own
C<SMACK64EXEC> label, in which case the process will transition to run under that label. When not
specified, the label that systemd is running under is used. This directive is ignored if SMACK is
disabled.

The value may be prefixed by C<->, in which case all errors will be ignored. An empty
value may be specified to unset previous assignments. This does not affect commands prefixed with
C<+>.',
      'StandardError' => 'Controls where file descriptor 2 (stderr) of the executed processes is connected to. The
available options are identical to those of C<StandardOutput>, with some exceptions: if set to
C<inherit> the file descriptor used for standard output is duplicated for standard error, while
C<fd:name> will use a default file descriptor name of
C<stderr>.

This setting defaults to the value set with C<DefaultStandardError> in
L<systemd-system.conf(5)>, which
defaults to C<inherit>. Note that setting this parameter might result in additional dependencies
to be added to the unit (see above).',
      'StandardInput' => "Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one
of C<null>, C<tty>, C<tty-force>, C<tty-fail>,
C<data>, C<file:path>, C<socket> or
C<fd:name>.

If C<null> is selected, standard input will be connected to C</dev/null>,
i.e. all read attempts by the process will result in immediate EOF.

If C<tty> is selected, standard input is connected to a TTY (as configured by
C<TTYPath>, see below) and the executed process becomes the controlling process of the
terminal. If the terminal is already being controlled by another process, the executed process waits until the
current controlling process releases the terminal.

C<tty-force> is similar to C<tty>, but the executed process is forcefully and
immediately made the controlling process of the terminal, potentially removing previous controlling processes
from the terminal.

C<tty-fail> is similar to C<tty>, but if the terminal already has a
controlling process start-up of the executed process fails.

The C<data> option may be used to configure arbitrary textual or binary data to pass via
standard input to the executed process. The data to pass is configured via
C<StandardInputText>/C<StandardInputData> (see below). Note that the actual
file descriptor type passed (memory file, regular file, UNIX pipe, \x{2026}) might depend on the kernel and available
privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by
EOF.

The C<file:path> option may be used to connect a specific file

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

effect.

Commands prefixed with C<+> are not subject to filtering. The
execve(), exit(), exit_group(),
getrlimit(), rt_sigreturn(),
sigreturn() system calls and the system calls for querying time and sleeping are
implicitly allow-listed and do not need to be listed explicitly.

The default action when a system call is denied is to terminate the processes with a
C<SIGSYS> signal. This can changed using C<SystemCallErrorNumber>,
see below. In addition, deny-listed system calls and system call groups may optionally be suffixed
with a colon (C<:>) and an argument in the same format as
C<SystemCallErrorNumber>, to take this action when the matching system call is made.
This takes precedence over the action specified in C<SystemCallErrorNumber>.

This feature makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp
filtering') and is useful for enforcing a minimal sandboxing environment.

Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn
off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this
option. Specifically, it is recommended to combine this option with
C<SystemCallArchitectures=native> or similar.

Note that strict system call filters may impact execution and error handling code paths of the
service invocation. Specifically, access to the execve() system call is required
for the execution of the service binary \x{2014} if it is blocked service invocation will necessarily fail.
Also, if execution of the service binary fails for some reason (for example: missing service
executable), the error handling logic might require access to an additional set of system calls in
order to process and log this failure correctly. It might be necessary to temporarily disable system
call filters in order to allow debugging of such failures.

If you specify both types of this option (i.e. allow-listing and deny-listing), the first
encountered will take precedence and will dictate the default action (termination or approval of a
system call). Then the next occurrences of this option will add or delete the listed system calls
from the set of the filtered system calls, depending of its type and the default action. (For
example, if you have started with an allow list rule for read() and
write(), and right after it add a deny list rule for write(),
then write() will be removed from the set.)

As the number of possible system calls is large, predefined groups of system calls are
provided. A group starts with C<\@> character, followed by name of the set.
Currently predefined system call setsSetDescription\@aioAsynchronous I/O (L<io_setup(2)>, L<io_submit(2)>, and related
calls)\@basic-ioSystem calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing
(L<read(2)>, L<write(2)>, and related calls)\@chownChanging file ownership (L<chown(2)>, L<fchownat(2)>, and related
calls)\@clockSystem calls for changing the system clock (L<adjtimex(2)>, L<settimeofday(2)>, and related
calls)\@cpu-emulationSystem calls for CPU emulation functionality (L<vm86(2)> and related calls)\@debugDebugging,
performance monitoring and tracing functionality (L<ptrace(2)>, L<perf_event_open(2)> and related
calls)\@file-systemFile system operations: opening, creating files and directories for read and write, renaming and
removing them, reading file properties, or creating hard and symbolic links\@io-eventEvent loop system calls
(L<poll(2)>, L<select(2)>, L<epoll(7)>, L<eventfd(2)> and related calls)\@ipcPipes, SysV IPC, POSIX Message Queues and
other IPC (L<mq_overview(7)>, L<svipc(7)>)\@keyringKernel keyring access (L<keyctl(2)> and related calls)\@memlockLocking
of memory in RAM (L<mlock(2)>, L<mlockall(2)> and related calls)\@moduleLoading and unloading of kernel modules
(L<init_module(2)>, L<delete_module(2)> and related calls)\@mountMounting and unmounting of file systems (L<mount(2)>,
L<chroot(2)>, and related calls)\@network-ioSocket I/O (including local AF_UNIX): L<socket(7)>,
L<unix(7)>\@obsoleteUnusual, obsolete or unimplemented (L<create_module(2)>, L<gtty(2)>, \x{2026})\@pkeySystem calls that deal
with memory protection keys (L<pkeys(7)>)\@privilegedAll system calls which need super-user capabilities
(L<capabilities(7)>)\@processProcess control, execution, namespacing operations (L<clone(2)>, L<kill(2)>,
L<namespaces(7)>, \x{2026})\@raw-ioRaw I/O port access (L<ioperm(2)>, L<iopl(2)>, pciconfig_read(), \x{2026})\@rebootSystem calls for
rebooting and reboot preparation (L<reboot(2)>, kexec(), \x{2026})\@resourcesSystem calls for changing resource limits, memory
and scheduling parameters (L<setrlimit(2)>, L<setpriority(2)>, \x{2026})\@sandboxSystem calls for sandboxing programs
(L<seccomp(2)>, Landlock system calls, \x{2026})\@setuidSystem calls for changing user ID and group ID credentials,
(L<setuid(2)>, L<setgid(2)>, L<setresuid(2)>, \x{2026})\@signalSystem calls for manipulating and handling process signals
(L<signal(2)>, L<sigprocmask(2)>, \x{2026})\@swapSystem calls for enabling/disabling swap devices (L<swapon(2)>,
L<swapoff(2)>)\@syncSynchronizing files and memory to disk (L<fsync(2)>, L<msync(2)>, and related calls)\@system-serviceA
reasonable set of system calls used by common system services, excluding any special purpose calls. This is the
recommended starting point for allow-listing system calls for system services, as it contains what is typically needed
by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: C<\@clock>,
C<\@mount>, C<\@swap>, C<\@reboot>.\@timerSystem calls for scheduling operations by time (L<alarm(2)>, L<timer_create(2)>,
\x{2026})\@knownAll system calls defined by the kernel. This list is defined statically in systemd based on a kernel version
that was available when this systemd version was released. It will become progressively more out-of-date as the kernel
is updated.
Note, that as new system calls are added to the kernel, additional system calls might be added to the groups
above. Contents of the sets may also change between systemd versions. In addition, the list of system calls
depends on the kernel version and architecture for which systemd was compiled. Use
systemd-analyze\x{a0}syscall-filter to list the actual list of system calls in each
filter.

Generally, allow-listing system calls (rather than deny-listing) is the safer mode of
operation. It is recommended to enforce system call allow lists for all long-running system
services. Specifically, the following lines are a relatively safe basic choice for the majority of
system services:

    [Service]
    SystemCallFilter=\@system-service
    SystemCallErrorNumber=EPERM

Note that various kernel system calls are defined redundantly: there are multiple system calls
for executing the same operation. For example, the pidfd_send_signal() system
call may be used to execute operations similar to what can be done with the older
kill() system call, hence blocking the latter without the former only provides
weak protection. Since new system calls are added regularly to the kernel as development progresses,
keeping system call deny lists comprehensive requires constant work. It is thus recommended to use
allow-listing instead, which offers the benefit that new system calls are by default implicitly
blocked until the allow list is updated.

Also note that a number of system calls are required to be accessible for the dynamic linker to
work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF
binaries, which is how most distributions build packaged programs). This means that blocking these
system calls (which include open(), openat() or
mmap()) will make most programs typically shipped with generic distributions
unusable.

It is recommended to combine the file system namespacing related options with
C<SystemCallFilter=~\@mount>, in order to prohibit the unit's processes to undo the
mappings. Specifically these are the options C<PrivateTmp>,
C<PrivateDevices>, C<ProtectSystem>, C<ProtectHome>,
C<ProtectKernelTunables>, C<ProtectControlGroups>,
C<ProtectKernelLogs>, C<ProtectClock>, C<ReadOnlyPaths>,
C<InaccessiblePaths> and C<ReadWritePaths>.",
      'SystemCallLog' => 'Takes a space-separated list of system call names. If this setting is used, all
system calls executed by the unit processes for the listed ones will be logged. If the first
character of the list is C<~>, the effect is inverted: all system calls except the
listed system calls will be logged. This feature makes use of the Secure Computing Mode 2 interfaces
of the kernel (\'seccomp filtering\') and is useful for auditing or setting up a minimal sandboxing
environment. This option may be specified more than once, in which case the filter masks are merged.
If the empty string is assigned, the filter is reset, all prior assignments will have no effect.
This does not affect commands prefixed with C<+>.',
      'TTYColumns' => 'Configure the size of the TTY specified with C<TTYPath>. If unset or
set to the empty string, it is attempted to retrieve the dimensions of the terminal screen via ANSI
sequences, and if that fails the kernel defaults (typically 80x24) are used.',
      'TTYPath' => 'Sets the terminal device node to use if standard input, output, or error are connected to a TTY