journald: deprecate SplitMode=login (#3805)

In this mode, messages from processes which are not part of the session
land in the main journal file, and only output of processes which are
properly part of the session land in the user's journal. This is
confusing, in particular because systemd-coredump runs outside of the
login session.

"Deprecate" SplitMode=login by removing it from documentation, to
discourage people from using it.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2016-07-26 02:19:33 -04:00 committed by Lennart Poettering
parent dadd6ecfa5
commit 76153ad45f
3 changed files with 17 additions and 18 deletions

7
NEWS
View File

@ -1,5 +1,12 @@
systemd System and Service Manager
CHANGES WITH 232 in spe
* Journald's SplitMode=login setting has been deprecated. It has been
removed from documentation, and it's use is discouraged. In a future
release it will be completely removed, and made equivalent to current
default of SplitMode=uid.
CHANGES WITH 231:
* In service units the various ExecXYZ= settings have been extended

View File

@ -129,23 +129,15 @@
<varlistentry>
<term><varname>SplitMode=</varname></term>
<listitem><para>Controls whether to split up journal files per user. Split-up journal files are primarily
useful for access control: on UNIX/Linux access control is managed per file, and the journal daemon will assign
users read access to their journal files. This setting takes one of <literal>uid</literal>,
<literal>login</literal> or <literal>none</literal>. If <literal>uid</literal>, all regular users will get each
their own journal files regardless of whether their processes possess login sessions or not, however system
users will log into the system journal. If <literal>login</literal>, actually logged-in users will get each
their own journal files, but users without login session and system users will log into the system
journal. Note that in this mode, user code running outside of any login session will log into the system log
instead of the split-out user logs. Most importantly, this means that information about core dumps of user
processes collected via the
<citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry> subsystem
will end up in the system logs instead of the user logs, and thus not be accessible to the owning users. If
<literal>none</literal>, journal files are not split up by user and all messages are instead stored in the
single system journal. In this mode unprivileged users generally do not have access to their own log data. Note
that splitting up journal files by user is only available for journals stored persistently. If journals are
stored on volatile storage (see above), only a single journal file for all user IDs is kept. Defaults to
<literal>uid</literal>.</para></listitem>
<listitem><para>Controls whether to split up journal files per user, either <literal>uid</literal> or
<literal>none</literal>. Split journal files are primarily useful for access control: on UNIX/Linux access
control is managed per file, and the journal daemon will assign users read access to their journal files. If
<literal>uid</literal>, all regular users will each get their own journal files, and system users will log to
the system journal. If <literal>none</literal>, journal files are not split up by user and all messages are
instead stored in the single system journal. In this mode unprivileged users generally do not have access to
their own log data. Note that splitting up journal files by user is only available for journals stored
persistently. If journals are stored on volatile storage (see <varname>Storage=</varname> above), only a single
journal file is used. Defaults to <literal>uid</literal>.</para></listitem>
</varlistentry>
<varlistentry>

View File

@ -43,7 +43,7 @@ typedef enum Storage {
typedef enum SplitMode {
SPLIT_UID,
SPLIT_LOGIN,
SPLIT_LOGIN, /* deprecated */
SPLIT_NONE,
_SPLIT_MAX,
_SPLIT_INVALID = -1