[systemd-devel] keyrings and dbus

[Simon McVittie]

On Wed, 12 Jun 2019 at 19:57:39 +0300, Andrei Borzenkov wrote:
> 12.06.2019 19:18, Simon McVittie пишет:
> > systemd user services are not part of a particular login session. They
> > exist outside all login sessions (look at systemd-cgls).
> > 
> gnome-terminal surely *is* part of particular login session.
> Unfortunately it is spawned by gnome-terminal-server which itself is
> started as systemd user session inside sytsemd-user ... session?

The gnome-terminal launcher stub (/usr/bin/gnome-terminal) is part of
a particular login session, but does not persist beyond startup. All it
does is to communicate with gnome-terminal-server and then exit.

gnome-terminal-server exists outside the scope of any particular login
session, and is the component that actually draws windows and runs
a shell.

This has the consequence that GNOME Terminal windows, and the shell that
runs inside them, are drawn onto the X11 or Wayland display that belongs
to a login session, but are not actually part of that login session. You
can see this by looking at the process and cgroup hierarchies.

> > It's your choice - but you can't have it both ways. The dbus-daemon
> > can't be both inside a login session, and shared between login sessions.
> 
> But that means that as long as there are applications that are part of
> user session and started by dbus-daemon, dbus-daemon simply cannot be
> part of systemd-user, correct?

I'm very deliberately using the term "login session" because it is a
jargon term identifying a specific thing in the conceptual model used
by systemd-logind, which is essentially the same as the conceptual model
used by non-systemd things like PAM and Linux audit.

A process enters a login session in privileged code (like login(1) or gdm
or similar) at the transition between "not logged in" and "logged in". All
children of a process that is in a login session are in the same login
session; if a process that is not in any login session starts a child
process, the child is also not in any login session, unless the parent
process is privileged and is deliberately starting a new login session.
In systemd, a login session is represented by the session-$N.scope cgroup,
where $N is the session ID.

"User session" means something different: in D-Bus, we use it to refer
to the collection of processes belonging to a user who currently has
at least one login session. It includes all their login sessions (even
if there is more than one), as well as things that belong to that user
but are not in a login session, like systemd --user. In systemd, a user
session is represented by the user-$UID.slice cgroup, where $UID is the
user's numeric uid.

systemd --user is not part of a login session. If you are starting
dbus-daemon --session as a child process of systemd --user, then the
definitions above mean that the dbus-daemon is not part of a login
session either.

(dbus-daemon is never part of systemd --user - it's a separate process
running a separate executable - but it can be a child process of
systemd --user, or not, depending whether you started it using its
systemd user unit or via dbus-launch or some other way.)

If dbus-daemon is outside the login session, and you are also starting
applications via D-Bus activation, like gnome-terminal-server (either as
child processes of dbus-daemon, or as child processes of systemd --user
via dbus-daemon's support for delegating activation to systemd), then
those processes are also not part of a login session - even though they
might be drawing their X11 or Wayland windows as though they were! Again,
this is a consequence of the definition used for a login session: it is
defined in terms of the process hierarchy, not the X11 or Wayland display,
so connecting to a login session's X11 or Wayland display cannot make
you part of that login session.

    smcv