systemd DynamicUser= services v.s. journald splits

Question

systemd-journald has the default config SplitMode=uid, to create individual journal (log) files for each user, which they are allowed to read.

When running services with DynamicUser=, does this mean the service may be able to read the logs of random old DynamicUser= services?

And if so, are there potential concerns (security?) of being able to read a journal file which is not strictly your own?

EDIT: surely there is a concern about coredumps which systemd saves either as separate files or in the journal? (systemd-coredump)

---

The blog post for DynamicUser= does not mention the journal, when discussing the implications of re-using UIDs.

http://0pointer.net/blog/dynamic-users-with-systemd.html

You may wonder why system users are generally not deallocated when the package that registered them is uninstalled from a system (at least on most distributions). The reason for that is one relevant property of the user concept (you might even want to call this a design flaw): user IDs are sticky to files (and other objects such as IPC objects). If a service running as a specific system user creates a file at some location, and is then terminated and its package and user removed, then the created file still belongs to the numeric ID ("UID") the system user originally got assigned. When the next system user is allocated and — due to ID recycling — happens to get assigned the same numeric ID, then it will also gain access to the file, and that's generally considered a problem, given that the file belonged to a potentially very different service once upon a time, and likely should not be readable or changeable by anything coming after it. Distributions hence tend to avoid UID recycling which means system users remain registered forever on a system after they have been allocated once.

...

In order to counter the problem, two strategies easily come to mind:

1. Prohibit the service from creating any files/directories or IPC objects

2. Automatically removing the files/directories or IPC objects the service created when it shuts down.

In systemd we implemented both strategies, but for different parts of the execution environment...

Answer 1

There is no security issue with this. (I checked in systemd v239).

Users in the UID range used by DynamicUser=, cannot read their own systemd journal or systemd coredumps. The same restriction applies to "system" users (usually UID < 1000) and nobody.

---

https://github.com/systemd/systemd/blob/v239/src/coredump/coredump.c#L157

if (uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY)
        return 0;


/* Make sure normal users can read (but not write or delete)
 * their own coredumps */

https://github.com/systemd/systemd/blob/v239/src/journal/journald-server.c#L225

static bool uid_for_system_journal(uid_t uid) {

        /* Returns true if the specified UID shall get its data stored in the system journal*/

        return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY;
}

Answer 2

SplitMode=uid simply means the journal is split into different files for different systemd instances of each user, for for uid 1000's systemd, one for pid1 (system journal) and the access mode is set accordingly by the journald daemon. Currently, you cannot split it in any other way, which I think is a shame.