[systemd-devel] keyrings and dbus

[Topi Miettinen]

On 13.6.2019 20.52, Simon McVittie wrote:
> On Thu, 13 Jun 2019 at 15:43:36 +0300, Topi Miettinen wrote:
>> 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?
> 
> I don't think so. Consider these two scenarios, which I hope you'll agree
> should both be allowed:
> 
> * ssh user at mymachine
> * with the ssh session still open, log in to gdm on mymachine as user
> 
> * log in to gdm on mymachine as user
> * with the X11 or Wayland session still open, ssh user at mymachine
> 
> If systemd --user is part of a login session, then in each case it would
> have to be started as a child process of the first way you logged in.
> This would result in your dbus-daemon --session and your
> gnome-terminal-server belonging to your ssh login session in the first
> scenario, and your graphical login session in the second (even though
> in both cases, gnome-terminal-server is drawing windows onto your
> graphical login session).
> 
> It gets even weirder if you log out from the first login session, leaving
> the second one logged in, and the long-running systemd --user and
> dbus-daemon --session as members of a login session that no longer exists.
> 
> The "user-session" concept is primarily useful when login sessions overlap
> like this: typically you'd have 0-1 graphical login sessions (gdm, etc.),
> 0 or more remote login sessions (ssh, etc.), 0 or more login sessions on
> a virtual console or serial console (getty/login) and 0 or more cron jobs.

These are valid cases. But I think the ssh session would not actually 
need most of the services launched by systemd --user, like 
gnome-terminal-server in your example.

Perhaps the answer is then not to use systemd --user, but my motivation 
to maximise use of systemd is that then I can use its containment 
features, like seccomp easily and tuned for each process, like 
pulseaudio and redshift. For the ssh login session, these would not be 
started at all (ideally) as they are useless in that login session.

>> Or the reverse, start the login session by systemd --user?
> 
> systemd --user is unprivileged and does not provide a transition from
> not-logged-in to logged-in state (it isn't in the same position as login,
> sshd, gdm, cron etc.), so it cannot start login sessions.

I meant that gdm would do the privileged transition and then it would 
just start unprivileged systemd --user, which would launch rest of X11 
setup.

-Topi