view release on metacpan or  search on metacpan

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

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.',
        'replace' => {
          '0' => 'no',
          '1' => 'yes',
          'false' => 'no',
          'true' => 'yes'
        },
        'type' => 'leaf',
        'upstream_default' => 'no',
        'value_type' => 'enum'
      },
      'ProtectHostname',
      {
        'choice' => [
          'no',
          'private',
          'yes'
        ],
        'description' => '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
hostname changes dynamically.

Note that this option does not prevent changing system hostname via hostnamectl.
However, C<User> and C<Group> may be used to run as an unprivileged user
to disallow changing system hostname. See SetHostname() in
L<org.freedesktop.hostname1(5)>
for more details.',
        'replace' => {
          '0' => 'no',
          '1' => 'yes',
          'false' => 'no',
          'true' => 'yes'
        },
        'type' => 'leaf',
        'upstream_default' => 'no',
        'value_type' => 'enum'
      },
      'ProtectClock',
      {
        'description' => '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.',
        'type' => 'leaf',
        'upstream_default' => 'no',
        'value_type' => 'boolean',
        'write_as' => [
          'no',
          'yes'
        ]
      },
      'ProtectKernelTunables',
      {
        'description' => 'Takes a boolean argument. If true, kernel variables accessible through
C</proc/sys/>, C</sys/>, C</proc/sysrq-trigger>,
C</proc/latency_stats>, C</proc/acpi>,
C</proc/timer_stats>, C</proc/fs> and C</proc/irq> will
be made read-only and C</proc/kallsyms> as well as C</proc/kcore> will be
inaccessible to all processes of the unit.
Usually, tunable kernel variables should be initialized only at boot-time, for example with the
L<sysctl.d(5)> mechanism. Few
services need to write to these at runtime; it is hence recommended to turn this on for most services. For this
setting the same restrictions regarding mount propagation and privileges apply as for
C<ReadOnlyPaths> and related calls, see above. Defaults to off.
Note that this option does not prevent indirect changes to kernel tunables affected by IPC calls to
other processes. However, C<InaccessiblePaths> may be used to make relevant IPC file system
objects inaccessible. If C<ProtectKernelTunables> is set,
C<MountAPIVFS=yes> is implied.',
        'type' => 'leaf',
        'upstream_default' => 'no',
        'value_type' => 'boolean',
        'write_as' => [
          'no',
          'yes'
        ]
      },
      'ProtectKernelModules',

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

system object to standard input. An absolute path following the C<:> character is expected,
which may refer to a regular file, a FIFO or special file. If an C<AF_UNIX> socket in the
file system is specified, a stream socket is connected to it. The latter is useful for connecting standard
input of processes to arbitrary system services.

The C<socket> option is valid in socket-activated services only, and requires the relevant
socket unit file (see
L<systemd.socket(5)> for details)
to have C<Accept=yes> set, or to specify a single socket only. If this option is set, standard
input will be connected to the socket the service was activated from, which is primarily useful for
compatibility with daemons designed for use with the traditional L<inetd(8)> socket activation
daemon (C<\$LISTEN_FDS> (and related) environment variables are not passed when
C<socket> value is configured).

The C<fd:name> option connects standard input to a specific,
named file descriptor provided by a socket unit. The name may be specified as part of this option, following a
C<:> character (e.g. C<fd:foobar>). If no name is specified, the name
C<stdin> is implied (i.e. C<fd> is equivalent to C<fd:stdin>).
At least one socket unit defining the specified name must be provided via the C<Sockets>
option, and the file descriptor name may differ from the name of its containing socket unit. If multiple
matches are found, the first one will be used. See C<FileDescriptorName> in
L<systemd.socket(5)> for more
details about named file descriptors and their ordering.

This setting defaults to C<null>, unless
C<StandardInputText>/C<StandardInputData> are set, in which case it
defaults to C<data>.",
        'type' => 'leaf',
        'value_type' => 'enum'
      },
      'StandardOutput',
      {
        'choice' => [
          'inherit',
          'journal',
          'journal+console',
          'kmsg',
          'kmsg+console',
          'null',
          'socket',
          'tty'
        ],
        'description' => "Controls where file descriptor 1 (stdout) of the executed processes is connected
to. Takes one of C<inherit>, C<null>, C<tty>,
C<journal>, C<kmsg>, C<journal+console>,
C<kmsg+console>, C<file:path>,
C<append:path>, C<truncate:path>,
C<socket> or C<fd:name>.

C<inherit> duplicates the file descriptor of standard input for standard output.

C<null> connects standard output to C</dev/null>, i.e. everything written
to it will be lost.

C<tty> connects standard output to a tty (as configured via C<TTYPath>,
see below). If the TTY is used for output only, the executed process will not become the controlling process of
the terminal, and will not fail or wait for other processes to release the terminal. Note: if a unit
tries to print multiple lines to a TTY during bootup or shutdown, then there's a chance that those
lines will be broken up by status messages. SetShowStatus() can be used to
prevent this problem. See
L<org.freedesktop.systemd1(5)>
for details.

C<journal> connects standard output with the journal, which is accessible via
L<journalctl(1)>. Note
that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the
specific option listed below is hence a superset of this one. (Also note that any external,
additional syslog daemons receive their log data from the journal, too, hence this is the option to
use when logging shall be processed with such a daemon.)

C<kmsg> connects standard output with the kernel log buffer which is accessible via
L<dmesg(1)>,
in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which
case this option is no different from C<journal>.

C<journal+console> and C<kmsg+console> work in a similar way as the
two options above but copy the output to the system console as well.

The C<file:path> option may be used to connect a specific file
system object to standard output. The semantics are similar to the same option of
C<StandardInput>, see above. If path refers to a regular file
on the filesystem, it is opened (created if it does not exist yet using privileges of the user executing the
systemd process) for writing at the beginning of the file, but without truncating it.
If standard input and output are directed to the same file path, it is opened only once \x{2014} for reading as well
as writing \x{2014} and duplicated. This is particularly useful when the specified path refers to an
C<AF_UNIX> socket in the file system, as in that case only a
single stream connection is created for both input and output.

C<append:path> is similar to
C<file:path> above, but it opens the file in append mode.

C<truncate:path> is similar to
C<file:path> above, but it truncates the file when opening
it. For units with multiple command lines, e.g. C<Type=oneshot> services with
multiple C<ExecStart>, or services with C<ExecCondition>,
C<ExecStartPre> or C<ExecStartPost>, the output file is reopened
and therefore re-truncated for each command line. If the output file is truncated while another
process still has the file open, e.g. by an C<ExecReload> running concurrently with
an C<ExecStart>, and the other process continues writing to the file without
adjusting its offset, then the space between the file pointers of the two processes may be filled
with C<NUL> bytes, producing a sparse file. Thus,
C<truncate:path> is typically only useful for units where
only one process runs at a time, such as services with a single C<ExecStart> and no
C<ExecStartPost>, C<ExecReload>, C<ExecStop> or
similar.

C<socket> connects standard output to a socket acquired via socket activation. The
semantics are similar to the same option of C<StandardInput>, see above.

The C<fd:name> option connects standard output to a
specific, named file descriptor provided by a socket unit. A name may be specified as part of this
option, following a C<:> character
(e.g. C<fd:foobar>). If no name is specified, the name
C<stdout> is implied (i.e. C<fd> is equivalent to
C<fd:stdout>). At least one socket unit defining the specified name must be provided
via the C<Sockets> option, and the file descriptor name may differ from the name of
its containing socket unit. If multiple matches are found, the first one will be used. See
C<FileDescriptorName> in
L<systemd.socket(5)>
for more details about named descriptors and their ordering.