[systemd-devel] Display manager and logind interaction

[Robert Ancell]

On 12 February 2012 02:33, Lennart Poettering <lennart at poettering.net> wrote:
> On Sat, 11.02.12 22:14, Robert Ancell (robert.ancell at gmail.com) wrote:
>> Questions:
>>
>> - There are cases where switching users needs to be performed by the
>> DM, e.g. if switching should go to a new session for authentication
>> before unlocking the requested session or if you're using a non-VT
>> based multiplexer. To achieve this would a "ActivateSession" signal be
>> needed on the Seat object for the DM to listen to?
>
> "a non-VT based multiplexer"? Does that exist? Currently we only support
> kernel-VT multi-session (and that means only for seat0, but not for the
> others).
>
> I am not sure I understand the question.

I'll run through some examples.

For the first point you have a system when two sessions (A and B
running on two different VTs) are open.  Session B requests a switch
to session A using a fast user switcher UI.  Under the current logind
this request would be made to the logind D-Bus service and that would
activate VT A via the kernel.  Most current desktops would show a
password dialog which would be covering the session to unlock it.  The
recommended way of doing this in LightDM (work in progress) is instead
to trigger a new greeter running on VT C, perform the authentication
there using the same method as a normal login (with associated
security benefits) and then unlock session A and switch to VT A once
authentication is completed.  For this to work with the current logind
I think you would have to do two VT switches or not tell logind which
VT sessions A and B are on.

I don't know of current non-VT based multiplexers but my prediction
the display server architecture (probably something Wayland based?) we
are moving towards (and how LightDM is being architected) is that we
are moving to each session rendering to an offscreen buffer and there
is a master compositor doing transitions between sessions /
redirecting input.

For example if we repeat the two session case now there is the master
compositor running on VT1, and both sessions are either not on a VT at
all or both on VT1 (depending on how you look at it).  The master
compositor needs to know when switching to session A so it can do the
appropriate compositor effect between the two offscreen buffers and
redirect where input is going.

>> - In the above case a VT switch might be the wrong thing to do, do you
>> see a method of disabling the VT switch?  e.g. Could you register the
>> session with a hint so logind doesn't try and switch to it?
>
> Hmm? logind does not switch session son its own. It will just do so if
> some client requests is, and it will follow if the user switches
> sessions or if somebody calls the kernel ioctls.

See above.  Note this does imply the kernel VT ioctls are not a
suitable method for session switching.

>> - There are other types of switches, e.g. switch to a guest account -
>> do you see a method of signalling this through systemd?  Associated is
>> the ability for a UI to check if it has permissions for the various
>> switch types.
>
> I am not sure I understand "switch types". Can you elaborate?

The main cases I think are:
- Switch to existing session (supported with logind)
- Switch to a new session (i.e. showing a greeter to choose user /
session type etc) (*)
- Switch to a new session for a particular user (i.e. the fast user
switcher case)
- Switch to a new session for a KDE session for user X (not
particularly likely but a case may come up requiring settings some
session choices)
- Switch to guest session (i.e. a temporary user session)

>> - Can a logged in user request a new session on their seat? i.e.
>> switch to a login screen to start a new session
>
> logind does not know anything about "roles" (or is "class" a better name
> for this?) of logind session, i.e. whether something is a DM greeter
> session, or a DM lock screen or something like that. We could add this
> easily however, for example via an XDG_SESSION_ROLE env var for the PAM
> stack, or so.
>
> Anyway, not sure I grok your question, please elaborate!

That definitely sounds useful but I'm referring to the starred case above here.

>> - Where do you any seat specific configuration stored, e.g. what
>> greeter is running on that seat / what sessions are allowed?  (Should
>> a DM have additional configuration keyed by seat IDs?).
>
> Right now only one DM can run at a time. It is expected to take
> posession of all available seats.
>
> We probably could make this more flexible and have a property per seat
> which tells DMs whether they are the ones which should take posession of
> a seat, but I am not sure about the usecase for this. Unless there's
> really good reason to run multiple DMs each managing a different subset
> of seats at the same time I see no reason why we should add
> infrastructure for this.
>
> The seat IDs should be quite stable, they are built from the device
> paths. I.e. include the stable bits of the PCI/USB addressing. That
> means a seat plugged into USB port 1 should always carry the same name.
>
> In general I recommend to keep things as stateless as possible. i.e. do
> not create configuration files automatically just because the user
> plugged something in. Instead, create configuration only and exclusively
> if the user explicitly tries to configure a seat specifically.

I'll give another example:

Say you have an internet cafe with 5 seats running from one computer
in multi-seat configuration.   One computer is used by the owner and
the other 4 by customers.  You may want the owners computer to be set
up slightly differently, e.g. the customer computers automatically log
into a guest session and the owners run a sysadmin session.

I don't know of any particular cases where this is important but I
suspect there will inevitably be a case where using multi-seat
requires some difference between the seats that is more than hardware.
 I'm just hoping we can find a common place to put configuration in
this case so we don't get lots of double configuration for the seat
properties.  The configuration wouldn't need to be more complex than a
few variables / a key file.  (My guess is udev might cover all this
but I don't know enough about it to say).

>> A wikipage like
>> http://www.freedesktop.org/wiki/Software/systemd/localed would be much
>> appreciated for logind, even if it just contains a dump of the current
>> interface and a quick paragraph.
>
> Yes, we definitely plan to add this. So far we didn't want to declare
> the API for this stable however. But since gdm is now including client
> side code for this it's probably about time we document this interface.

Thanks!