"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
-<refentry id="systemd.resource-control">
+<refentry id="systemd.resource-control" xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd.resource-control</title>
<productname>systemd</productname>
<term><varname>IPAddressDeny=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term>
<listitem>
- <para>Turn on address range network traffic filtering for IP packets sent and received over
- <constant>AF_INET</constant> and <constant>AF_INET6</constant> sockets. Both directives take a
+ <para>Turn on network traffic filtering for IP packets sent and received over
+ <constant>AF_INET</constant> and <constant>AF_INET6</constant> sockets. Both directives take a
space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix
- length in bits (separated by a <literal>/</literal> character). If the latter is omitted, the
- address is considered a host address, i.e. the prefix covers the whole address (32 for IPv4, 128
- for IPv6).</para>
+ length in bits after a <literal>/</literal> character. If the suffix is omitted, the address is
+ considered a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for
+ IPv6).</para>
<para>The access lists configured with this option are applied to all sockets created by processes
of this unit (or in the case of socket units, associated with it). The lists are implicitly
combined with any lists configured for any of the parent slice units this unit might be a member
- of. By default all access lists are empty. Both ingress and egress traffic is filtered by these
+ of. By default both access lists are empty. Both ingress and egress traffic is filtered by these
settings. In case of ingress traffic the source IP address is checked against these access lists,
- in case of egress traffic the destination IP address is checked. When configured the lists are
- enforced as follows:</para>
+ in case of egress traffic the destination IP address is checked. The following rules are applied in
+ turn:</para>
<itemizedlist>
- <listitem><para>Access will be granted in case an IP packet's destination/source address matches
- any entry in the <varname>IPAddressAllow=</varname> setting.</para></listitem>
+ <listitem><para>Access is granted when the checked IP address matches an entry in the
+ <varname>IPAddressAllow=</varname> list.</para></listitem>
- <listitem><para>Otherwise, access will be denied in case its destination/source address matches
- any entry in the <varname>IPAddressDeny=</varname> setting.</para></listitem>
+ <listitem><para>Otherwise, access is denied when the checked IP address matches an entry in the
+ <varname>IPAddressDeny=</varname> list.</para></listitem>
- <listitem><para>Otherwise, access will be granted.</para></listitem>
+ <listitem><para>Otherwise, access is granted.</para></listitem>
</itemizedlist>
- <para>In order to implement a whitelisting IP firewall, it is recommended to use a
- <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit (such as the
- root slice <filename>-.slice</filename> or the slice containing all system services
+ <para>In order to implement an allow-listing IP firewall, it is recommended to use a
+ <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit
+ (such as the root slice <filename>-.slice</filename> or the slice containing all system services
<filename>system.slice</filename> – see
- <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
- details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname> lines
- permitting network access to relevant services, and only them.</para>
-
- <para>Note that for socket-activated services, the IP access list configured on the socket unit applies to
- all sockets associated with it directly, but not to any sockets created by the ultimately activated services
- for it. Conversely, the IP access list configured for the service is not applied to any sockets passed into
- the service via socket activation. Thus, it is usually a good idea, to replicate the IP access lists on both
- the socket and the service unit, however it often makes sense to maintain one list more open and the other
- one more restricted, depending on the usecase.</para>
+ <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ for details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname>
+ lines permitting network access to relevant services, and only them.</para>
+
+ <para>Note that for socket-activated services, the IP access list configured on the socket unit
+ applies to all sockets associated with it directly, but not to any sockets created by the
+ ultimately activated services for it. Conversely, the IP access list configured for the service is
+ not applied to any sockets passed into the service via socket activation. Thus, it is usually a
+ good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless,
+ it may make sense to maintain one list more open and the other one more restricted, depending on
+ the usecase.</para>
<para>If these settings are used multiple times in the same unit the specified lists are combined. If an
empty string is assigned to these settings the specific access list is reset and all previous settings undone.</para>
</varlistentry>
<varlistentry>
- <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAMM_PATH</replaceable></varname></term>
- <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAMM_PATH</replaceable></varname></term>
+ <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term>
+ <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term>
<listitem>
<para>Add custom network traffic filters implemented as BPF programs, applying to all IP packets
<para>The device node specifier is either a path to a device node in the file system, starting with
<filename>/dev/</filename>, or a string starting with either <literal>char-</literal> or
<literal>block-</literal> followed by a device group name, as listed in
- <filename>/proc/devices</filename>. The latter is useful to whitelist all current and future
+ <filename>/proc/devices</filename>. The latter is useful to allow-list all current and future
devices belonging to a specific device group at once. The device group is matched according to
filename globbing rules, you may hence use the <literal>*</literal> and <literal>?</literal>
wildcards. (Note that such globbing wildcards are not available for device node path
all pseudo TTYs and all ALSA sound devices, respectively. <literal>char-cpu/*</literal> is a
specifier matching all CPU related device groups.</para>
- <para>Note that whitelists defined this way should only reference device groups which are
+ <para>Note that allow lists defined this way should only reference device groups which are
resolvable at the time the unit is started. Any device groups not resolvable then are not added to
- the device whitelist. In order to work around this limitation, consider extending service units
+ the device allow list. In order to work around this limitation, consider extending service units
with a pair of <command>After=modprobe@xyz.service</command> and
<command>Wants=modprobe@xyz.service</command> lines that load the necessary kernel module
implementing the device group if missing.
hierarchy. Accordingly, access to the specified controllers will not be granted to unprivileged services on
the legacy hierarchy, even when requested.</para>
- <para>The following controller names may be specified: <option>cpu</option>, <option>cpuacct</option>,
- <option>io</option>, <option>blkio</option>, <option>memory</option>, <option>devices</option>,
- <option>pids</option>. Not all of these controllers are available on all kernels however, and some are
+ <xi:include href="supported-controllers.xml" xpointer="controllers-text" />
+
+ <para>Not all of these controllers are available on all kernels however, and some are
specific to the unified hierarchy while others are specific to the legacy hierarchy. Also note that the
kernel might support further controllers, which aren't covered here yet as delegation is either not supported
at all for them or not defined cleanly.</para>
to disable. Passing <varname>DisableControllers=</varname> by itself with no controller name present resets
the disabled controller list.</para>
- <para>Valid controllers are <option>cpu</option>, <option>cpuacct</option>, <option>io</option>,
- <option>blkio</option>, <option>memory</option>, <option>devices</option>, and <option>pids</option>.</para>
+ <xi:include href="supported-controllers.xml" xpointer="controllers-text" />
</listitem>
</varlistentry>
</variablelist>
projects / thirdparty / systemd.git / blobdiff