Config-Model-Systemd
9 results

 view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Section/Service.pod  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 — 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)>, …)@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)>, …)@raw-ioRaw I/O port access (L<ioperm(2)>, L<iopl(2)>, pciconfig_read(), …)@rebootSystem calls for
rebooting and reboot preparation (L<reboot(2)>, kexec(), …)@resourcesSystem calls for changing resource limits, memory
and scheduling parameters (L<setrlimit(2)>, L<setpriority(2)>, …)@sandboxSystem calls for sandboxing programs
(L<seccomp(2)>, Landlock system calls, …)@setuidSystem calls for changing user ID and group ID credentials,
(L<setuid(2)>, L<setgid(2)>, L<setresuid(2)>, …)@signalSystem calls for manipulating and handling process signals
(L<signal(2)>, L<sigprocmask(2)>, …)@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)>,
…)@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 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>. I< Optional. Type list of uniline.  > 

=head2 SystemCallErrorNumber

Takes an C<errno> error number (between 1 and 4095) or errno name
such as C<EPERM>, C<EACCES> or C<EUCLEAN>, to
return when the system call filter configured with C<SystemCallFilter> is triggered,
instead of terminating the process immediately. See L<errno(3)> for a
full list of error codes. When this setting is not used, or when the empty string or the special
setting C<kill> is assigned, the process will be terminated immediately when the
filter is triggered. I< Optional. Type uniline.  > 

=head2 SystemCallArchitectures

lib/Config/Model/models/Systemd/Section/Service.pod  view on Meta::CPAN 

removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are
passed on as-is. This only applies to log messages written to stdout or stderr. For details about
this prefixing see
L<sd-daemon(3)>.
Defaults to true. I< Optional. Type boolean.  > 

=over 4

=item upstream_default value :

yes

=back



=head2 TTYPath

Sets the terminal device node to use if standard input, output, or error are connected to a TTY
(see above). Defaults to C</dev/console>. I< Optional. Type uniline.  > 

=head2 TTYReset

Reset the terminal device specified with C<TTYPath> before and after
execution. This does not erase the screen (see C<TTYVTDisallocate> below for
that). Defaults to C<no>. I< Optional. Type uniline.  > 

=head2 TTYVHangup

Disconnect all clients which have opened the terminal device specified with
C<TTYPath> before and after execution. Defaults to C<no>. I< Optional. Type uniline.  > 

=head2 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. I< Optional. Type uniline.  > 

=head2 TTYRows

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. I< Optional. Type uniline.  > 

=head2 TTYVTDisallocate

If the terminal device specified with C<TTYPath> is a virtual
console terminal, try to deallocate the TTY before and after execution. This ensures that the screen
and scrollback buffer is cleared. If the terminal device is of any other type of TTY an attempt is
made to clear the screen via ANSI sequences. Defaults to C<no>. I< Optional. Type uniline.  > 

=head2 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 —
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 — 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<…/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)> – 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. I< Optional. Type uniline.  > 

=head2 LoadCredentialEncrypted

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 —
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 — 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<…/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)> – 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. I< Optional. Type uniline.  > 

=head2 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 —
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. I< Optional. Type uniline.  > 

=head2 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. I< Optional. Type uniline.  > 

=head2 SetCredentialEncrypted

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. I< Optional. Type uniline.  > 

=head2 UtmpIdentifier

Takes a four character identifier string for an L<utmp(5)> and wtmp entry
for this service. This should only be set for services such as getty implementations (such
as L<agetty(8)>) where utmp/wtmp
entries must be created and cleared before and after execution, or for services that shall be executed as if
they were run by a getty process (see below). If the configured string is longer than four
characters, it is truncated and the terminal four characters are used. This setting interprets %I style string
replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this
service. I< Optional. Type uniline.  > 

=head2 UtmpMode

Takes one of C<init>, C<login> or C<user>. If
C<UtmpIdentifier> is set, controls which type of L<utmp(5)>/wtmp entries
for this service are generated. This setting has no effect unless C<UtmpIdentifier> is set
too. If C<init> is set, only an C<INIT_PROCESS> entry is generated and the
invoked process must implement a getty-compatible utmp/wtmp logic. If
C<login> is set, first an C<INIT_PROCESS> entry, followed by a
C<LOGIN_PROCESS> entry is generated. In this case, the invoked process must implement a
L<login(1)>-compatible
utmp/wtmp logic. If C<user> is set, first an C<INIT_PROCESS> entry, then a
C<LOGIN_PROCESS> entry and finally a C<USER_PROCESS> entry is
generated. In this case, the invoked process may be any process that is suitable to be run as session
leader. Defaults to C<init>. I< Optional. Type enum. choice: 'init', 'login', 'user'.  > 

=head2 KillMode

Specifies how processes of this unit shall be killed. One of
C<control-group>, C<mixed>, C<process>,
C<none>.

If set to C<control-group>, all remaining processes in the control group of this
unit will be killed on unit stop (for services: after the stop command is executed, as configured
with C<ExecStop>). If set to C<mixed>, the
C<SIGTERM> signal (see below) is sent to the main process while the subsequent
C<SIGKILL> signal (see below) is sent to all remaining processes of the unit's
control group. If set to C<process>, only the main process itself is killed (not
recommended!). If set to C<none>, no process is killed (strongly recommended
against!). In this case, only the stop command will be executed on unit stop, but no process will be
killed otherwise.  Processes remaining alive after stop are left in their control group and the
control group continues to exist after stop unless empty.

Note that it is not recommended to set C<KillMode> to
C<process> or even C<none>, as this allows processes to escape
the service manager's lifecycle and resource management, and to remain running even while their
service is considered stopped and is assumed to not consume any resources.

Processes will first be terminated via C<SIGTERM> (unless the signal to send
is changed via C<KillSignal> or C<RestartKillSignal>). Optionally,
this is immediately followed by a C<SIGHUP> (if enabled with
C<SendSIGHUP>). If processes still remain after:
the main process of a unit has exited (applies to C<KillMode>:
C<mixed>)the delay configured via the C<TimeoutStopSec> has passed
(applies to C<KillMode>: C<control-group>, C<mixed>,
C<process>)
the termination request is repeated with the C<SIGKILL> signal or the signal specified via

lib/Config/Model/models/Systemd/Section/Service.pod  view on Meta::CPAN 

L<Control Group v2|https://docs.kernel.org/admin-guide/cgroup-v2.html>. In case of
both C<stop> and C<kill>, the service ultimately ends up in the
C<oom-kill> failed state after which C<Restart> may apply.

Defaults to the setting C<DefaultOOMPolicy> in
L<systemd-system.conf(5)>
is set to, except for units where C<Delegate> is turned on, where it defaults to
C<continue>.

Use the C<OOMScoreAdjust> setting to configure whether processes of the unit
shall be considered preferred or less preferred candidates for process termination by the Linux OOM
killer logic. See
L<systemd.exec(5)> for
details.

This setting also applies to
L<systemd-oomd.service(8)>.
Similarly to the kernel OOM kills performed by the kernel, this setting determines the state of the
unit after systemd-oomd kills a cgroup associated with it. I< Optional. Type uniline.  > 

=head2 OpenFile

Takes an argument of the form C<path:fd-name:options>,
where:
C<path> is a path to a file or an C<AF_UNIX> socket in the file system;C<fd-name> is a name that will be associated
with the file descriptor;
the name may contain any ASCII character, but must exclude control characters and ":", and must be at most 255
characters in length;
it is optional and, if not provided, defaults to the file name;C<options> is a comma-separated list of access options;
possible values are
C<read-only>,
C<append>,
C<truncate>,
C<graceful>;
if not specified, files will be opened in C<rw> mode;
if C<graceful> is specified, errors during file/socket opening are ignored.
Specifying the same option several times is treated as an error.
The file or socket is opened by the service manager and the file descriptor is passed to the service.
If the path is a socket, we call connect() on it.
See L<sd_listen_fds(3)>
for more details on how to retrieve these file descriptors.

This setting is useful to allow services to access files/sockets that they cannot access themselves
(due to running in a separate mount namespace, not having privileges, ...).

This setting can be specified multiple times, in which case all the specified paths are opened and the file descriptors
passed to the service.
If the empty string is assigned, the entire list of open files defined prior to this is reset. I< Optional. Type uniline.  > 

=head2 ReloadSignal

Configures the UNIX process signal to send to the service's main process when asked
to reload the service's configuration. Defaults to C<SIGHUP>. This option has no
effect unless C<Type>=C<notify-reload> is used, see
above. I< Optional. Type uniline.  > 

=head2 RefreshOnReload

Takes a boolean argument, or a list of resources defined in
L<systemd.exec(5)>.
Possible values are C<extensions> and C<credentials>, separated by space.
Prepending the list with a single tilde character (C<~>) inverts the effect.
Defaults to C<extensions>. An empty assignment resets the list to default. If enabled,
the corresponding resources (C<ExtensionImages>/C<ExtensionDirectories>
for C<extensions> and C<LoadCredential>/C<ImportCredential>/
C<SetCredential> (along with their C<Encrypted> counterparts)
for C<credentials>) will be refreshed on service reload. If C<yes>,
all resources listed above that are used by the service shall be refreshed.

Specially, if this option is set explicitly, and the respective resources are in use,
the service may be reloaded without any actual reload mechanism (C<ExecReload>
or C<Type=notify-reload>) for notifying the main process, in which case the reload
is considered complete immediately after refreshing. I< Optional. Type uniline.  > 

=head2 FailureAction

B<Deprecated> I< Optional. Type uniline.  > 

=head2 SuccessAction

B<Deprecated> I< Optional. Type uniline.  > 

=head2 StartLimitBurst

B<Deprecated> I< Optional. Type uniline.  > 

=head2 StartLimitInterval

B<Deprecated> I< Optional. Type uniline.  > 

=head2 RebootArgument

B<Deprecated> I< Optional. Type uniline.  > 

=head1 SEE ALSO

=over

=item *

L<cme>

=back

=head1 COPYRIGHT

=over

=item 2010-2016 Lennart Poettering and others

=item 2016 Dominique Dumont


=back

=head1 LICENSE

=over

=item LGPLv2.1+


=back

=cut



( run in 0.544 second using v1.01-cache-2.11-cpan-39bf76dae61 )