[systemd-devel] keyrings and dbus

[Topi Miettinen]

On 12.6.2019 22.20, Simon McVittie wrote:
> 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.

The sessions with slightly different scopes might be useful in some 
cases. But if this is not the case, would it be possible to unify the 
scopes and make systemd --user part of the login session? Now it is 
started by PID1, but in that case it probably should be started by 
pam_systemd.so or more directly (e.g. /etc/X11/Xsession.d/00systemd)? Or 
the reverse, start the login session by systemd --user? I've tried 
lightly both approaches but there always seems to be some problems.

-Topi