[systemd-devel] Display manager and logind interaction

[Lennart Poettering]

On Sun, 12.02.12 11:33, Robert Ancell (robert.ancell at gmail.com) wrote:

> 
> 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 see the value in a logic like this, but I see serious problems in
implementing thisi ATM. First of all, what do you do if the user presses
C-A-Fx to switch to some session x? Do you then immediately forward him
to the locking VT instead? And the same problem would arise if some user
code use chvt(1) to switch sessions.

And on seats != "seat0" we currently don't have any kind of session
multiplexing. Hence having a special VT for lock screens is really hard
to do... (I have actually discussed this topic with the Wayland guys at
FOSDEM and we'll probably have userspace VT switching based on Wayland
one day, but that's work for the future).

I am tempted to say that until the moment we do VT switching in
userspace with Wayland implementing proper lock screens is really hard,
and probably not worth the effort.

> 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.

Yes, this is what Kristian has in mind: we'll have a system compositor
that basically implements VT switching and suchlike in userspace and not
only works on the first framebuffer but on all.

> 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.

Well, with Wayland the entire notion of kernel VTs would go
away. Instead, the system compositor could simply redirect VT numbers to
different sessions dynamically.

> > 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) (*)

My assumption here is actually that in a Wayland world the display
manager never closes his greeter session, and it thus always stays around.

> - Switch to a new session for a particular user (i.e. the fast user
> switcher case)

If we have Wayland it should be relatively easy implementing
virtualized/software VT switching in logind.

> - 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)

We explicitly want to forbid multiple local graphical sessions by the
same user in systemd.

> > 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.

OK, I'll implement XDG_SESSION_CLASS for this now. It probably makes
sense to have this property defined right from the beginning if we want
display managers to set it.

> 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).

systemd isn't really in the business of providing configuration
storage. But it should be fairly easy to key off the seat name for these
uses, and we even explicitly document that the seat name is suitable for
inclusion in file names. For example, if you write a display manager
then you could just read per-seat configuration from
/etc/my-display-manager/<seat-names>.conf and then fall back to
/etc/my-display-manager/default.conf if no such file exists.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.