Hi, On Fri, Apr 17, 2020 at 8:45 AM Benjamin Berg <bb...@redhat.com> wrote: > I feel that this means that we conceptually have a "composite" session > that consists of multiple "normal" logind sessions. And I wonder if we > could make this singleton "composite" session an explicit concept > rather than something that purely exists implicitly. This concept of a "composite session" you speak of already exists in logind. In logind nomenclature it's called a "user".
> In the "simple" implementation, we could expect each desktop > environment to handle all this themselves. i.e. gnome-session would > launch, see there is already an existing one, and then do an > appropriate call to "attach" the new seat and remain dormant until it > should/needs to be detached again. I don't think gnome-session needs to do much beyond what it's already doing. It just needs to make sure systemd is told what services to start, if they aren't already started (which target to reach) > While possible, I see the disadvantages that, > 1. GDM/the greeter cannot know whether attaching is possible, GDM certainly can (and already does) know if the user already has a running session. > 2. the user could try launching a different session type Launching different session types should be supported. I mean, if the user is already running a local kms ("wayland") session, and then starts a "pipewire", mutter should detect and handle that. I think it would even be possible in theory (though maybe hard in practice with mutter, and of dubious value) to support "x11" and "wayland" at the same time. > 3. we would likely get different implementations with varying degree > of brokenness. Not sure what you're saying here, can you reiterate? > Right now to login/create a session we do: > * GDM starts helper process right, we call that a "session worker" > * Helper does pam authentication and creates pam session, right. > * pam_logind moves helper into scope and attaches an FD for watching pam_systemd, but yea it should have been called pam_logind :-) Right, and to be clear, this is where session registration happens. pam_systemd use's logind's dbus api to say "Here's a new wayland session" or "here's a new Xorg session". > * Helper effectively launches the user's session processes Yup, the session worker forks off the session from here, and sticks around to tell PAM when the session is over, too. > What if, instead, the user can only have one "composite" graphical > session from GDMs point of view (which may not support multiple "real" > sessions, e.g. in the case of X11). > > We can have calls in logind to manage such a composite session, i.e.: > * attach a new "real" logind session > * detach a "real" logind session > * create a new "composite" session with an existing "real" session So I don't understand why attaching a session would be a separate step from creating the session. logind automatically attaches all new sessions to the user ("composite session" in your nomenclature). why wouldn't you want it to continue to do that? Is the point that you want to support multiple concurrent composite sessions for a user? If so, what if those concurrent sessions share services? All of a sudden those services need to not only see what sessions they're in, but also need to see what composite sessions they're in? > Session creation itself could be delegated to systemd-logind. The funny > thing is, that then GDM may never need to launch user processes. It > would go through PAM for authentication, and then from there just call > the "attach" or "create" method. So historically, the reason things have been done the way they are, is because PAM has these notions of credentials and environment that PAM modules can influence. The simplest example is environment variables, which can be fairly easily transferred out from the session worker, but there's also, for example, creating a session specific kernel keyring, assigning supplementary groups, instituting ulimits, etc. Basically the PAM modules can do blackbox things to the the process running the pam conversation and expect those "things" to get passed on to the children of that process, to the session getting opened. Btw, PAM also expects, in some cases to be able to update those "things" at unlock time. A canonical example would be a kerberos ticket put on the session keyring. The ticket gets assigned at login, and renewed when the user types their password at the unlock screen. In order to make that sort of thing work, GDM jumps through some contortions to make the session worker used for unlocking be forked from the session worker used for login. (Though these days kerberos tickets aren't put on the session keyring). Now in a world where most of the session is running from a user context anyway, obviously the users session, today, isn't picking up all those things. This has created some problems, for instance, https://bugzilla.gnome.org/show_bug.cgi?id=780622 But, that just means we need to change how those "things" (limits, credentials, resources, environment, whatever) are imposed on the user's processes. It's something we need to fix on an as needed basis, basically. Anyway, that's a long winded way of me saying, there is a reason it was done the way it was, and there are implications to changing it. Whether it's worth doing anyway, is a different question, of course. > What could this mean? > > 1. Launching a graphical session becomes entirely the job of logind So is the idea that logind starts parsing /usr/share/xsessions, /usr/share/wayland-sessions files, or we ditch those and switch purely to systemd targets ? Or, in this model, are we sending what to execute straight to logind? > 2. GDM could solely create dummy sessions (for authentication), and > delegate the rest to logind. > 3. The dummy sessions could probably be stripped down to returning > an FD, they may not even need a persistent process/scope anymore. > 4. Control over the session's environment is removed from the display > manager. > Please, let's stop passing around environment variables! I'm all for easing our way off environment variable dependence, we just have to make sure we don't break stuff in the process... > 5. X11 sessions requiring Xorg might be interesting. Could work by > still letting GDM start Xorg in the original session, or > standardising a procedure on the logind side. So Xorg these days runs as the user instead of as root, so there's no reason in theory it couldn't be fixed to run from systemd service files instead of from getting launched in the session by gdm-x-session. I think I even wrote code for it once a long time ago: https://cgit.freedesktop.org/~halfline/xserver/commit/?h=wip/logind-integration&id=f02bae74d10fd8fccb69de61014fdb3b3f26efce > I am sure what I am proposing here is potentially a huge pain for e.g. > flickerfree operations. But maybe letting logind start the user's > session is not completely crazy and could actually lead to a much > cleaner model overall? So I don't think it would cause a problem wrt to flicker, but I'm not sure the model is so much cleaner than status quo that it's worth the substantial effort to implement. I think the logind architecture that exists *today* is good enough to meet our needs (with maybe minor changes that don't affect the general architecture), so I'm a little apprehensive about changing it drastically. Anyway, such changes would need run through systemd-devel, of course. But, I really think, from a GNOME perspective, we can get a remote desktop that does the curtaining, and works with systemd --user with very little changes to logind (just the ones I mentioned in my last mail). --Ray _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel