On Sun, 12.02.12 11:33, Robert Ancell ([email protected]) wrote: > > On 12 February 2012 02:33, Lennart Poettering <[email protected]> wrote: > > On Sat, 11.02.12 22:14, Robert Ancell ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
