Config-Model-Systemd

 view release on metacpan or  search on metacpan

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

group.

If the parameter is C<identity>, user namespacing is set up with an identity
mapping for the first 65536 UIDs/GIDs. Any UIDs/GIDs above 65536 will be mapped to the
C<nobody> user and group, respectively. While this does not provide UID/GID isolation,
since all UIDs/GIDs are chosen identically it does provide process capability isolation, and hence is
often a good choice if proper user namespacing with distinct UID maps is not appropriate.

If the parameter is C<full>, user namespacing is set up with an identity
mapping for all UIDs/GIDs. In addition, for system services, C<full> allows the unit
to call setgroups() system calls (by setting
C</proc/pid/setgroups> to C<allow>).
Similar to C<identity>, this does not provide UID/GID isolation, but it does provide
process capability isolation. If this mode is enabled, all unit processes are run without privileges
in the host user namespace (regardless of whether the unit\'s own user/group is
C<root> or not). Specifically this means that the process will have zero process
capabilities on the host\'s user namespace, but full capabilities within the service\'s user
namespace. Settings such as C<CapabilityBoundingSet> will affect only the latter,
and there\'s no way to acquire additional capabilities in the host\'s user namespace.

If the parameter is C<managed> a transient, dynamically allocated range of
65536 UIDs/GIDs is allocated for the unit, and a UID/GID mapping is assigned to the unit\'s process
so the UID/GID 0 from inside the unit maps to the first UID/GID of the allocated mapping. Note that
in this mode the UID/GID the service process will run as is different depending if looking from the
host side (where it will be a high, dynamically assigned UID) or from inside the unit (where it will
be 0). Also note that this mode will enable file system UID mapping for the file systems this service
accesses, mapping the "foreign" UID range on disk to the selected dynamic UID range at
runtime.

When this setting is set up by a per-user instance of the service manager, the mapping of the
C<root> user and group to itself is omitted (unless the user manager is root).
Additionally, in the per-user instance manager case, the
user namespace will be set up before most other namespaces. This means that combining
C<PrivateUsers>=C<true> with other namespaces will enable use of features not
normally supported by the per-user instances of the service manager.

This setting is particularly useful in conjunction with
C<RootDirectory>/C<RootImage>, as the need to synchronize the user and group
databases in the root directory and on the host is reduced, as the only users and groups who need to be matched
are C<root>, C<nobody> and the unit\'s own user and group.',
      'ProcSubset' => 'Takes one of C<all> (the default) and C<pid>. If
C<pid>, all files and directories not directly associated with process management and
introspection are made invisible in the C</proc/> file system configured for the
unit\'s processes. This controls the C<subset=> mount option of the
C<procfs> instance for the unit. For further details see L<The /proc
Filesystem|https://docs.kernel.org/filesystems/proc.html#mount-options>. Note that Linux exposes various kernel APIs
via C</proc/>,
which are made unavailable with this setting. Since these APIs are used frequently this option is
useful only in a few, specific cases, and is not suitable for most non-trivial programs.

Much like C<ProtectProc> above, this is implemented via file system mount
namespacing, and hence the same restrictions apply: it is only available to system services, it
disables mount propagation to the host mount table, and it implies
C<MountAPIVFS>. Also, like C<ProtectProc> this setting is gracefully
disabled if the used kernel does not support the C<subset=> mount option of
C<procfs>.',
      'ProtectClock' => 'Takes a boolean argument. If set, writes to the hardware clock or system clock will
be denied. Defaults to off. Enabling this option removes C<CAP_SYS_TIME> and
C<CAP_WAKE_ALARM> from the capability bounding set for this unit, installs a system
call filter to block calls that can set the clock, and C<DeviceAllow=char-rtc r> is
implied. Note that the system calls are blocked altogether, the filter does not take into account
that some of the calls can be used to read the clock state with some parameter combinations.
Effectively, C</dev/rtc0>, C</dev/rtc1>, etc. are made read-only
to the service. See
L<systemd.resource-control(5)>
for the details about C<DeviceAllow>.

It is recommended to turn this on for most services that do not need modify the clock or check
its state.',
      'ProtectControlGroups' => 'Takes a boolean argument or the special values C<private> or
C<strict>. If true, the Linux Control Groups (L<cgroups(7)>) hierarchies
accessible through C</sys/fs/cgroup/> will be made read-only to all processes of the
unit. If set to C<private>, the unit will run in a cgroup namespace with a private
writable mount of C</sys/fs/cgroup/>. If set to C<strict>, the unit
will run in a cgroup namespace with a private read-only mount of C</sys/fs/cgroup/>.
Defaults to off. If C<ProtectControlGroups> is set, C<MountAPIVFS=yes>
is implied. Note C<private> and C<strict> are downgraded to false and
true respectively unless the system is using the unified control group hierarchy and the kernel supports
cgroup namespaces.

Except for container managers no services should require write access to the control groups hierarchies;
it is hence recommended to set C<ProtectControlGroups> to true or C<strict>
for most services. For this setting the same restrictions regarding mount propagation and privileges apply
as for C<ReadOnlyPaths> and related settings, see above.',
      'ProtectHome' => 'Takes a boolean argument or the special values C<read-only> or
C<tmpfs>. If true, the directories C</home/>,
C</root>, and C</run/user> are made inaccessible and empty for
processes invoked by this unit. If set to C<read-only>, the three directories are
made read-only instead. If set to C<tmpfs>, temporary file systems are mounted on the
three directories in read-only mode. The value C<tmpfs> is useful to hide home
directories not relevant to the processes invoked by the unit, while still allowing necessary
directories to be made visible when listed in C<BindPaths> or
C<BindReadOnlyPaths>.

Setting this to C<yes> is mostly equivalent to setting the three directories in
C<InaccessiblePaths>. Similarly, C<read-only> is mostly equivalent to
C<ReadOnlyPaths>, and C<tmpfs> is mostly equivalent to
C<TemporaryFileSystem> with C<:ro>.

It is recommended to enable this setting for all long-running services (in particular
network-facing ones), to ensure they cannot get access to private user data, unless the services
actually require access to the user\'s private data. This setting is implied if
C<DynamicUser> is set. This setting cannot ensure protection in all cases. In
general it has the same limitations as C<ReadOnlyPaths>, see below.

Note that this setting provides no protection if home directories are placed at a non-standard
location, i.e. outside of the hierarchies listed above.',
      'ProtectHostname' => 'Takes a boolean argument or C<private>. If enabled, sets up a new UTS
namespace for the executed processes. If enabled, a hostname can be optionally specified following a
colon (e.g. C<yes:foo> or C<private:host.example.com>), and the
hostname is set in the new UTS namespace for the unit. If set to a true value, changing hostname or
domainname via sethostname() and setdomainname() system
calls is prevented. If set to C<private>, changing hostname or domainname is allowed
but only affects the unit\'s UTS namespace. Defaults to off.

Note that the implementation of this setting might be impossible (for example if UTS namespaces
are not available), and the unit should be written in a way that does not solely rely on this setting
for security.

Note that when this option is enabled for a service hostname changes no longer propagate from
the system into the service, it is hence not suitable for services that need to take notice of system

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

string removes previous assignments. For a list of valid mount options, please refer to
L<mount(8)>.

Valid partition names follow the
L<Discoverable Partitions
Specification|https://uapi-group.org/specifications/specs/discoverable_partitions_specification>:
C<root>, C<usr>, C<home>, C<srv>,
C<esp>, C<xbootldr>, C<tmp>,
C<var>.',
      'RootImagePolicy' => '*ExtensionImagePolicy',
      'RootMStack' => 'Takes a path to a
L<systemd.mstack(7)>
directory encapsulating a mount stack consisting of layers and bind mounts. Similar to
C<RootDirectory> and C<RootImage> this runs the service off a
distinct root file system, in this case set up via C<overlayfs>.

Since C<.mstack/> directories may reference disk images (DDIs) similar device
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

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

described in L<systemd.unit(5)>,
as well as C<x32>, C<mips64-n32>, C<mips64-le-n32>, and
the special identifier C<native>. The special identifier C<native>
implicitly maps to the native architecture of the system (or more precisely: to the architecture the system
manager is compiled for). By default, this option is set to the empty list, i.e. no filtering is applied.

If this setting is used, processes of this unit will only be permitted to call native system calls, and
system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated
as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on
x32.

System call filtering is not equally effective on all architectures. For example, on x86
filtering of network socket-related calls is not possible, due to ABI limitations \x{2014} a limitation that x86-64
does not have, however. On systems supporting multiple ABIs at the same time \x{2014} such as x86/x86-64 \x{2014} it is hence
recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to
circumvent the restrictions applied to the native ABI of the system. In particular, setting
C<SystemCallArchitectures=native> is a good choice for disabling non-native ABIs.

System call architectures may also be restricted system-wide via the
C<SystemCallArchitectures> option in the global configuration. See
L<systemd-system.conf(5)> for
details.",
      '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.',
      'SystemCallFilter' => "Takes a space-separated list of system call names or system call groups. If this
setting is used, system calls executed by the unit processes except for the listed ones will result
in the system call being denied (allow-listing). If the first character of the list is
C<~>, the effect is inverted: only the listed system calls will be denied
(deny-listing). 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.

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
(see above). Defaults to C</dev/console>.',
      '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>.',
      'TTYRows' => '*TTYColumns',
      'TTYVHangup' => 'Disconnect all clients which have opened the terminal device specified with
C<TTYPath> before and after execution. Defaults to C<no>.',
      '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>.',
      'TemporaryFileSystem' => 'Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file
system namespace is set up for executed processes, and a temporary file system is mounted on each mount point.
This option may be specified more than once, in which case temporary file systems are mounted on all listed mount
points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect.
Each mount point may optionally be suffixed with a colon (C<:>) and mount options such as
C<size=10%> or C<ro>. By default, each temporary file system is mounted
with C<nodev,strictatime,mode=0755>. These can be disabled by explicitly specifying the corresponding
mount options, e.g., C<dev> or C<nostrictatime>.

This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary
files or directories can be still accessed by combining with C<BindPaths> or
C<BindReadOnlyPaths>:

Example: if a unit has the following,

    TemporaryFileSystem=/var:ro
    BindReadOnlyPaths=/var/lib/systemd

then the invoked processes by the unit cannot see any files or directories under C</var/> except for
C</var/lib/systemd> or its contents.',
      'TimeoutCleanSec' => "Configures a timeout on the clean-up operation requested through systemctl
clean \x{2026}, see