[systemd-devel] Display manager and logind interaction

[Lennart Poettering]

On Sat, 11.02.12 22:14, Robert Ancell (robert.ancell at gmail.com) wrote:

Heya,

> I'm looking at the logind / display manager (DM) interaction and want
> to check if I grok it.

Thanks for looking into this. I'll put up a blog story soon detailing
a bit how DMs should be ported over to logind.

Here's a short summary:

(A) To do just the most basic porting, for the main seat, ignoring all
    multi-seat magic:

    - Strip all CK support for the DM
    - Make sure to set up a proper PAM session for the greeter user (and
      the PAM stack should include the pam_systemd module)
    - Make sure to set up a proper PAM session for the user login (also
      including pam_systemd)
    - If you have it, pass the VT number to the PAM module by using
      pam_setenv() for XDG_VTNR. You may also set XDG_SEAT to
      "seat0". Both of these are optional, but recommended.

(B) If you want to take benefit of the magic multi-seat stuff on top of (A):

    - Subscribe to SeatAdded/SeatRemoved signals of logind, and
      enumerate all seats initially using ListSeats() and then spawn a
      login on all seats found.
    - When setting up the PAM sessions you must set XDG_SEAT to the seat
      you are spawning things on (see above). It's also recommended to
      set XDG_VTNR (but only for seat0, since the others don't support
      VTs).
    - Pass the seat name to X via the "-seat" switch.
    - As a stop gap use /lib/systemd/systemd-multi-seat-x instead of the
      real binary, since the X server itself only knows to handle "-seat"
      for input devices, but is currently unable to do proper
      framebuffer enumeration using "-seat". This tiny wrapper emulates
      this and executes the real X, replacing the wrapper. This wrapper
      will go away as soon as X learned frame buffer enumeration using
      "-seat" natively. It's a temporary hack since replacing the PCI
      based enumeration of graphics cards to a udev-based one is a
      massive change to X.

And that's already it. (A) should be much simpler than for CK, simply
because DMs need to systemd specific code at all, everything goes
through PAM. And (B) should be pretty minimal too I hope.

> As I read it:
> 
> - A logind aware DM should get the list of seats to run from logind
> and watch for changes[1].

Yes.

> - When the DM starts a session it calls CreateSession on
> org.freedesktop.login1.Manager?  (The equivalent of
> OpenSessionWithParameters in CK?)

No, not necessary anymore. Just do PAM and leave this out.

> - Each seat should be configured (hardware wise) by what udev reports.

No need to do this explicitly. X does this on its own for input devices
and /lib/systemd/systemd-multi-seat-x will emulate this for graphics devices.

> - Sessions can be locked by using the logind interface (which checks
> permission to do this).  A lock aware session should listen to the
> Lock/Unlock signals on org.freedesktop.login1.Session and perform the
> required UI changes.  A lock aware DM can do the same thing.

Yes.

> - Sessions can be switched between by calling ActivateSession on
> org.freedesktop.login1.Seat.  This triggers a VT switch to the VT that
> session is on.

Yes.

> - The DM destroys the session with ?.

Just normal PAM session destruction calls, no special handling needed.

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

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

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

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

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

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.