mirror of
https://github.com/systemd/systemd.git
synced 2025-01-26 14:04:03 +03:00
Zbigniew Jędrzejewski-Szmek
GitHub
commit
1810976ba9
@ -698,12 +698,12 @@
|
||||
done. If set to <literal>grow</literal> the home area is grown to the size configured via
|
||||
<option>--disk-size=</option> should it currently be smaller. If it already matches the configured
|
||||
size or is larger no operation is executed. If set to <literal>shrink-and-grow</literal> the home
|
||||
area is also resized to the minimal size used disk space and file system constraints permit, during
|
||||
logout. This mode thus ensures that while a home area is activated it is sized to the configured
|
||||
size, but while deactivated it is compacted taking up only the minimal space possible. Note that if
|
||||
the system is powered off abnormally or if the user otherwise not logged out cleanly the shrinking
|
||||
operation will not take place, and the user has to re-login/logout again before it is executed
|
||||
again.</para></listitem>
|
||||
area is also resized during logout to the minimal size the used disk space and file system
|
||||
constraints permit. This mode thus ensures that while a home area is activated it is sized to the
|
||||
configured size, but while deactivated it is compacted taking up only the minimal space possible.
|
||||
Note that if the system is powered off abnormally or if the user otherwise not logged out cleanly the
|
||||
shrinking operation will not take place, and the user has to re-login/logout again before it is
|
||||
executed again.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -50,7 +50,7 @@
|
||||
<literal>UUID=</literal> followed by the UUID,
|
||||
<literal>PARTUUID=</literal> followed by the partition UUID,
|
||||
<literal>LABEL=</literal> followed by the label,
|
||||
<literal>PARTLABEL=</literal> followed by the partition label,
|
||||
<literal>PARTLABEL=</literal> followed by the partition label.
|
||||
</para>
|
||||
|
||||
<para>The third field if present contains an absolute filename path to a key file or a <literal>-</literal>
|
||||
|
||||
@ -94,7 +94,7 @@
|
||||
<term><varname>$SYSTEMD_NSS_RESOLVE_CACHE</varname></term>
|
||||
|
||||
<listitem><para>Takes a boolean argument. When false, the cache of previously queried records will
|
||||
not be used by <filename>systemd-resolved</filename>.</para></listitem>
|
||||
not be used by <command>systemd-resolved</command>.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
@ -121,7 +121,7 @@
|
||||
<term><varname>$SYSTEMD_NSS_RESOLVE_NETWORK</varname></term>
|
||||
|
||||
<listitem><para>Takes a boolean argument. When false, answers will be returned without using the
|
||||
network, i.e. either from local sources or the cache in <filename>systemd-resolved</filename>.
|
||||
network, i.e. either from local sources or the cache in <command>systemd-resolved</command>.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@ -130,8 +130,8 @@
|
||||
<refsect1>
|
||||
<title>Example</title>
|
||||
|
||||
<para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables <command>nss-resolve</command>
|
||||
correctly:</para>
|
||||
<para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables
|
||||
<command>nss-resolve</command> correctly:</para>
|
||||
|
||||
<!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
|
||||
<programlisting>passwd: compat systemd
|
||||
|
||||
@ -424,10 +424,10 @@
|
||||
<term><varname>PORTABLE_PREFIXES=</varname></term>
|
||||
<listitem><para>Takes a space-separated list of one or more valid prefix match strings for the
|
||||
<ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> logic. This field
|
||||
serves two purposes: it's informational, identifying portable service images as such (and thus
|
||||
allowing them to be distinguished from other OS images, such as bootable system images); whenever a
|
||||
portable service image is attached the specified or implied portable service prefix is checked
|
||||
against this list, to enforce restrictions how images may be attached to a
|
||||
serves two purposes: it is informational, identifying portable service images as such (and thus
|
||||
allowing them to be distinguished from other OS images, such as bootable system images). In is also
|
||||
used when a portable service image is attached: the specified or implied portable service prefix is
|
||||
checked against the list specified here, to enforce restrictions how images may be attached to a
|
||||
system.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
@ -1129,69 +1129,9 @@ $ systemd-analyze verify /tmp/source:alias.service
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<example>
|
||||
<title>JSON Policy</title>
|
||||
<para>The JSON file passed as a path parameter to <option>--security-policy=</option>
|
||||
has a top-level JSON object, with keys being the assessment test identifiers mentioned
|
||||
above. The values in the file should be JSON objects with one or more of the
|
||||
following fields: description_na (string), description_good (string), description_bad
|
||||
(string), weight (unsigned integer), and range (unsigned integer). If any of these fields
|
||||
corresponding to a specific id of the unit file is missing from the JSON object, the
|
||||
default built-in field value corresponding to that same id is used for security analysis
|
||||
as default. The weight and range fields are used in determining the overall exposure level
|
||||
of the unit files: the value of each setting is assigned a badness score, which is multiplied
|
||||
by the policy weight and divided by the policy range to determine the overall exposure that
|
||||
the setting implies. The computed badness is summed across all settings in the unit file,
|
||||
normalized to the 1…100 range, and used to determine the overall exposure level of the unit.
|
||||
By allowing users to manipulate these fields, the 'security' verb gives them the option to
|
||||
decide for themself which ids are more important and hence should have a greater effect on
|
||||
the exposure level. A weight of <literal>0</literal> means the setting will not be
|
||||
checked.</para>
|
||||
|
||||
<programlisting>
|
||||
{
|
||||
"PrivateDevices":
|
||||
{
|
||||
"description_good": "Service has no access to hardware devices",
|
||||
"description_bad": "Service potentially has access to hardware devices",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateMounts":
|
||||
{
|
||||
"description_good": "Service cannot install system mounts",
|
||||
"description_bad": "Service may install system mounts",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateNetwork":
|
||||
{
|
||||
"description_good": "Service has no access to the host's network",
|
||||
"description_bad": "Service has access to the host's network",
|
||||
"weight": 2500,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateTmp":
|
||||
{
|
||||
"description_good": "Service has no access to other software's temporary files",
|
||||
"description_bad": "Service has access to other software's temporary files",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateUsers":
|
||||
{
|
||||
"description_good": "Service does not have access to other users",
|
||||
"description_bad": "Service has access to other users",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
}
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
</listitem>
|
||||
<para>See example "JSON Policy" below.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--json=<replaceable>MODE</replaceable></option></term>
|
||||
|
||||
@ -1261,6 +1201,70 @@ $ systemd-analyze verify /tmp/source:alias.service
|
||||
|
||||
<xi:include href="common-variables.xml" />
|
||||
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
<example>
|
||||
<title>JSON Policy</title>
|
||||
|
||||
<para>The JSON file passed as a path parameter to <option>--security-policy=</option> has a top-level
|
||||
JSON object, with keys being the assessment test identifiers mentioned above. The values in the file
|
||||
should be JSON objects with one or more of the following fields: <option>description_na</option>
|
||||
(string), <option>description_good</option> (string), <option>description_bad</option> (string),
|
||||
<option>weight</option> (unsigned integer), and <option>range</option> (unsigned integer). If any of
|
||||
these fields corresponding to a specific id of the unit file is missing from the JSON object, the
|
||||
default built-in field value corresponding to that same id is used for security analysis as default.
|
||||
The weight and range fields are used in determining the overall exposure level of the unit files: the
|
||||
value of each setting is assigned a badness score, which is multiplied by the policy weight and divided
|
||||
by the policy range to determine the overall exposure that the setting implies. The computed badness is
|
||||
summed across all settings in the unit file, normalized to the 1…100 range, and used to determine the
|
||||
overall exposure level of the unit. By allowing users to manipulate these fields, the 'security' verb
|
||||
gives them the option to decide for themself which ids are more important and hence should have a
|
||||
greater effect on the exposure level. A weight of <literal>0</literal> means the setting will not be
|
||||
checked.</para>
|
||||
|
||||
<programlisting>
|
||||
{
|
||||
"PrivateDevices":
|
||||
{
|
||||
"description_good": "Service has no access to hardware devices",
|
||||
"description_bad": "Service potentially has access to hardware devices",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateMounts":
|
||||
{
|
||||
"description_good": "Service cannot install system mounts",
|
||||
"description_bad": "Service may install system mounts",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateNetwork":
|
||||
{
|
||||
"description_good": "Service has no access to the host's network",
|
||||
"description_bad": "Service has access to the host's network",
|
||||
"weight": 2500,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateTmp":
|
||||
{
|
||||
"description_good": "Service has no access to other software's temporary files",
|
||||
"description_bad": "Service has access to other software's temporary files",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
},
|
||||
"PrivateUsers":
|
||||
{
|
||||
"description_good": "Service does not have access to other users",
|
||||
"description_bad": "Service has access to other users",
|
||||
"weight": 1000,
|
||||
"range": 1
|
||||
}
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>See Also</title>
|
||||
<para>
|
||||
|
||||
@ -56,7 +56,9 @@
|
||||
</term>
|
||||
|
||||
<listitem><para>Create a block device <replaceable>volume</replaceable> using
|
||||
<replaceable>device</replaceable>. See integritytab man page and
|
||||
<replaceable>device</replaceable>. See
|
||||
<citerefentry><refentrytitle>systemd-integritytab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
and
|
||||
<ulink url="https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-integrity.html">
|
||||
Kernel dm-integrity</ulink> documentation for details.
|
||||
</para></listitem>
|
||||
|
||||
@ -1646,8 +1646,8 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
|
||||
<title>Build and boot a minimal Fedora distribution in a container</title>
|
||||
|
||||
<programlisting># dnf -y --releasever=&fedora_latest_version; --installroot=/var/lib/machines/f&fedora_latest_version; \
|
||||
--disablerepo='*' --enablerepo=fedora --enablerepo=updates install \
|
||||
systemd passwd dnf fedora-release vim-minimal glibc-minimal-langpack
|
||||
--repo=fedora --repo=updates --setopt=install_weak_deps=False install \
|
||||
passwd dnf fedora-release vim-minimal systemd systemd-networkd
|
||||
# systemd-nspawn -bD /var/lib/machines/f&fedora_latest_version;</programlisting>
|
||||
|
||||
<para>This installs a minimal Fedora distribution into the
|
||||
|
||||
@ -94,9 +94,12 @@
|
||||
then access them in this directory. This is supposed to be used to store auxiliary, encrypted,
|
||||
authenticated credentials for use with <varname>LoadCredentialEncrypted=</varname> in the UEFI System
|
||||
Partition. See
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
and
|
||||
<citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
for
|
||||
details on encrypted credentials. The generated <command>cpio</command> archive is measured into TPM
|
||||
PCR 4 (if a TPM is present)</para></listitem>
|
||||
PCR 4 (if a TPM is present).</para></listitem>
|
||||
|
||||
<listitem><para>Similarly, files <filename><replaceable>foo</replaceable>.efi.extra.d/*.raw</filename>
|
||||
are packed up in a <command>cpio</command> archive and placed in the <filename>/.extra/sysext/</filename>
|
||||
|
||||
@ -1964,9 +1964,7 @@ RestrictFileSystems=ext4</programlisting>
|
||||
</row>
|
||||
<row>
|
||||
<entry>@known</entry>
|
||||
<entry>All known filesystems 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.</entry>
|
||||
<entry>All known filesystems 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.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
||||
@ -812,7 +812,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>TransmitVLANSTAGHardwareAcceleration=</varname></term>
|
||||
<listitem>
|
||||
<para>Takes a boolean. If set to true, transmit VLAN STAG HW acceleration is enabled.
|
||||
<para>Takes a boolean. If set to true, transmit VLAN STAG hardware acceleration is enabled.
|
||||
When unset, the kernel's default will be used.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -824,12 +824,11 @@ Table=1234</programlisting></para>
|
||||
<varlistentry>
|
||||
<term><varname>DHCPPrefixDelegation=</varname></term>
|
||||
<listitem>
|
||||
<para>Takes a boolean value. When enabled, requests subnet prefixes acquired by a DHCPv6
|
||||
client, or by a DHCPv4 client through the 6RD option configured on another link. By default,
|
||||
an address within each delegated prefix will be assigned, and the prefixes will be announced
|
||||
through IPv6 Router Advertisement when <varname>IPv6SendRA=</varname> is enabled. Such
|
||||
default settings can be configured in the [DHCPPrefixDelegation] section. Defaults to
|
||||
disabled.</para>
|
||||
<para>Takes a boolean value. When enabled, requests subnet prefixes on another link via the DHCPv6
|
||||
protocol or via the 6RD option in the DHCPv4 protocol. An address within each delegated prefix will
|
||||
be assigned, and the prefixes will be announced through IPv6 Router Advertisement if
|
||||
<varname>IPv6SendRA=</varname> is enabled. This behaviour can be configured in the
|
||||
[DHCPPrefixDelegation] section. Defaults to disabled.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -2305,7 +2304,7 @@ Table=1234</programlisting></para>
|
||||
<citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_id128_from_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
and
|
||||
<citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
||||
<citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
|
||||
</para>
|
||||
<para>
|
||||
Note that the <literal>prefixstable</literal> algorithm uses both the interface
|
||||
@ -3686,7 +3685,7 @@ Token=prefixstable:2002:da8:1::</programlisting></para>
|
||||
<term><option>dst-host</option></term>
|
||||
<listitem><para>
|
||||
Flows are defined only by destination address. Equivalent to the
|
||||
<literal>srchost</literal> option for <command>tc qdisc</command> command. See also
|
||||
<literal>dsthost</literal> option for <command>tc qdisc</command> command. See also
|
||||
<citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -202,7 +202,7 @@
|
||||
capabilities (see
|
||||
<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for details). The <varname>AmbientCapability=</varname> setting
|
||||
specifies capability which will be passed to the started program
|
||||
specifies capabilities which will be passed to the started program
|
||||
in the inheritable and ambient capability sets. This will grant
|
||||
these capabilities to this process. This setting correspond to
|
||||
the <option>--ambient-capability=</option> command line switch.
|
||||
|
||||
@ -190,16 +190,16 @@
|
||||
<term><varname>TriggerLimitIntervalSec=</varname></term>
|
||||
<term><varname>TriggerLimitBurst=</varname></term>
|
||||
|
||||
<listitem><para>Configures a limit on how often this path unit may be activated within a specific time
|
||||
interval. The <varname>TriggerLimitIntervalSec=</varname> may be used to configure the length of the time
|
||||
interval in the usual time units <literal>us</literal>, <literal>ms</literal>, <literal>s</literal>,
|
||||
<literal>min</literal>, <literal>h</literal>, … and defaults to 2s (See
|
||||
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on
|
||||
the various time units understood). The <varname>TriggerLimitBurst=</varname> setting takes a positive integer
|
||||
value and specifies the number of permitted activations per time interval, and defaults to 200. Set either to
|
||||
0 to disable any form of trigger rate limiting. If the limit is hit, the unit is placed into a failure mode,
|
||||
and will not watch the path(s) anymore until restarted. Note that this limit is enforced before the service
|
||||
activation is enqueued.</para></listitem>
|
||||
<listitem><para>Configures a limit on how often this path unit may be activated within a specific
|
||||
time interval. The <varname>TriggerLimitIntervalSec=</varname> may be used to configure the length of
|
||||
the time interval in the usual time units <literal>us</literal>, <literal>ms</literal>,
|
||||
<literal>s</literal>, <literal>min</literal>, <literal>h</literal>, … and defaults to 2s. See
|
||||
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||||
details on the various time units understood. The <varname>TriggerLimitBurst=</varname> setting takes
|
||||
a positive integer value and specifies the number of permitted activations per time interval, and
|
||||
defaults to 200. Set either to 0 to disable any form of trigger rate limiting. If the limit is hit,
|
||||
the unit is placed into a failure mode, and will not watch the path(s) anymore until restarted. Note
|
||||
that this limit is enforced before the service activation is enqueued.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
@ -74,10 +74,10 @@
|
||||
<varlistentry>
|
||||
<term><option>--json=</option><replaceable>FORMAT</replaceable></term>
|
||||
|
||||
<listitem><para>Selects JSON out mode (like <option>--output=json</option>) and selects the precise
|
||||
display mode. Takes one of <literal>pretty</literal> or <literal>short</literal>. If
|
||||
<literal>pretty</literal> human-friendly whitespace and newlines are inserted in the output to make
|
||||
the JSON data more readable. If <literal>short</literal> all superfluous whitespace is
|
||||
<listitem><para>Selects JSON output mode (like <option>--output=json</option>) and selects the
|
||||
precise display mode. Takes one of <literal>pretty</literal> or <literal>short</literal>. If
|
||||
<literal>pretty</literal>, human-friendly whitespace and newlines are inserted in the output to make
|
||||
the JSON data more readable. If <literal>short</literal>, all superfluous whitespace is
|
||||
suppressed.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user