SymbX/systemd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

core: add new per-unit setting KeyringMode= for controlling kernel keyring setup

Browse Source 
Usually, it's a good thing that we isolate the kernel session keyring
for the various services and disconnect them from the user keyring.
However, in case of the cryptsetup key caching we actually want that
multiple instances of the cryptsetup service can share the keys in the
root user's user keyring, hence we need to be able to disable this logic
for them.

This adds KeyringMode=inherit|private|shared:

    inherit: don't do any keyring magic (this is the default in systemd --user)
    private: a private keyring as before (default in systemd --system)
    shared: the new setting
This commit is contained in:
Lennart Poettering
2017-09-15 16:53:35 +02:00
parent 4e962627bc
commit b1edf4456e
10 changed files with 144 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
man/systemd.exec.xml
+20
View File
@@ -1720,6 +1720,26 @@ CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
<varname>NoNewPrivileges=yes</varname> is implied.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>KeyringMode=</varname></term>
<listitem><para>Controls how the kernel session keyring is set up for the service (see <citerefentry
project='man-pages'><refentrytitle>session-keyring</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details on the session keyring). Takes one of <option>inherit</option>, <option>private</option>,
<option>shared</option>. If set to <option>inherit</option> no special keyring setup is done, and the kernel's
default behaviour is applied. If <option>private</option> is used a new session keyring is allocated when a
service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for
system services, as this ensures that multiple services running under the same system user ID (in particular
the root user) do not share their key material among each other. If <option>shared</option> is used a new
session keyring is allocated as for <option>private</option>, but the user keyring of the user configured with
<varname>User=</varname> is linked into it, so that keys assigned to the user may be requested by the unit's
processes. In this modes multiple units running processes under the same user ID may share key material. Unless
<option>inherit</option> is selected the unique invocation ID for the unit (see below) is added as a protected
key by the name <literal>invocation_id</literal> to the newly created session keyring. Defaults to
<option>private</option> for the system service manager and to <option>inherit</option> for the user service
manager.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>RuntimeDirectory=</varname></term>