Re: Chrome Remote Desktop and Wayland
Hi, On Fri, Apr 17, 2020 at 11:25 AM Benjamin Berg wrote: > > If so, I agree it's better if we don't have the user entering their > > password in their > > own session. In an ideal world we'd have a "secure attention" key or key > > sequence on the keyboard that users hit when it's time to type their > > password. > Yup. So I'll just add one other note... People expect to be able to blindly type their passwords to the lock screen and hit enter to get back to their session. I know from experience users get very upset if this feature is broken! If we add a SAK key they definitely wouldn't be able to do that anymore, but if we don't have a SAK key, there isn't really trusted path. Anyway doing unlock from tty1 is a good idea for other reasons (like systemd-homed), so it makes sense whether or not we pursue trusted path. --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Fri, 2020-04-17 at 11:18 -0400, Ray Strode wrote: > Hi, > > On Fri, Apr 17, 2020 at 9:58 AM Benjamin Berg > wrote: > > I do however think there is value in supporting such delegation from > > the logind side. A primary motivator for me here is systemd-homed, as > > it may freeze the user session, making it impossible to re-authenticate > > from within. > So my plan for systemd-homed was going to be to just make the GDM session > worker jump to VT1. Today, if we jump to VT1 a login screen will materialize > and all should just work. > > We could add some mechanism to logind to register where a login screen will go > and provide a way for logind to jump to that login screen instead, sure. Oh, true, I had not considered the possibility of doing this from the session worker. It just felt natural to me to enforce the VT switch on the logind level as it should know that the session is unusable. > > And really, it would be better if we don't let the user ever see their own > > password. > not sure what you mean by this. are you talking about ensuring trusted path? Yes, I meant having a trusted path for the password. > If so, I agree it's better if we don't have the user entering their > password in their > own session. In an ideal world we'd have a "secure attention" key or key > sequence on the keyboard that users hit when it's time to type their password. Yup. > > But, it should be as simple as logind forcing a VT switch to the > > correct greeter UI/session. Plus a little bit more magic to maybe spin > > up the UI in the background before suspending and pre-selecting the > > user to make the experience smoother. > Right, I'm definitely not opposed to api getting added to logind for > this, but I also > don't think it's strictly necessary. We can do it all from GDM pretty easily. > Probably when I play with systemd-homed I'll prototype things out on the GDM > side first. > > But, I also think this is an orthogonal discussion to remote desktop support. > (maybe one better for the systemd list?) Agreed. Benjamin signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi, On Fri, Apr 17, 2020 at 9:58 AM Benjamin Berg wrote: > I do however think there is value in supporting such delegation from > the logind side. A primary motivator for me here is systemd-homed, as > it may freeze the user session, making it impossible to re-authenticate > from within. So my plan for systemd-homed was going to be to just make the GDM session worker jump to VT1. Today, if we jump to VT1 a login screen will materialize and all should just work. We could add some mechanism to logind to register where a login screen will go and provide a way for logind to jump to that login screen instead, sure. > And really, it would be better if we don't let the user ever see their own > password. not sure what you mean by this. are you talking about ensuring trusted path? If so, I agree it's better if we don't have the user entering their password in their own session. In an ideal world we'd have a "secure attention" key or key sequence on the keyboard that users hit when it's time to type their password. > But, it should be as simple as logind forcing a VT switch to the > correct greeter UI/session. Plus a little bit more magic to maybe spin > up the UI in the background before suspending and pre-selecting the > user to make the experience smoother. Right, I'm definitely not opposed to api getting added to logind for this, but I also don't think it's strictly necessary. We can do it all from GDM pretty easily. Probably when I play with systemd-homed I'll prototype things out on the GDM side first. But, I also think this is an orthogonal discussion to remote desktop support. (maybe one better for the systemd list?) --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi,
On Fri, Apr 17, 2020 at 8:45 AM Benjamin Berg 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
Re: Chrome Remote Desktop and Wayland
Hi, On Fri, 2020-04-17 at 09:22 -0400, Ray Strode wrote: > On Fri, Apr 17, 2020 at 3:59 AM Marcel Hollerbach wrote: > > I really like the idea of curtaining the session. > > However, i am wondering if logind couldn't serve there as sort of > > gatekeeper > [...] > > The idea is that a session in logind can be locked or unlocked. In case > > it is locked, logind would spin up a "micro" session with a process that > > renders something to login. > > So you're saying logind would take on the function of e.g. GDM? > > I think logind is intentionally primarily about bookkeeping and resource > passing. The individual desktops want to be able to design the user > experience for their unlock screens. I don't think that it makes sense for logind to spin up such a micro- session, that is indeed something that needs to be delegated to GDM. I do however think there is value in supporting such delegation from the logind side. A primary motivator for me here is systemd-homed, as it may freeze the user session, making it impossible to re-authenticate from within. And really, it would be better if we don't let the user ever see their own password. But, it should be as simple as logind forcing a VT switch to the correct greeter UI/session. Plus a little bit more magic to maybe spin up the UI in the background before suspending and pre-selecting the user to make the experience smoother. Benjamin signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi, On Fri, Apr 17, 2020 at 3:59 AM Marcel Hollerbach wrote: > I really like the idea of curtaining the session. > However, i am wondering if logind couldn't serve there as sort of > gatekeeper [...] > The idea is that a session in logind can be locked or unlocked. In case > it is locked, logind would spin up a "micro" session with a process that > renders something to login. So you're saying logind would take on the function of e.g. GDM? I think logind is intentionally primarily about bookkeeping and resource passing. The individual desktops want to be able to design the user experience for their unlock screens. Also, in the olden days GDM used to have a separate "micro" session, itself. It had a perennial problem that things from a real session needed to be reimplemented in it. Things like keyboard layout choosing, accessibility features, system trays, etc. And so there was duplicated code, that had duplicate bugs, and the login screen UI provided a different experience than the logged in UI, which was suboptimal for the user. So that's why we changed GDM to actually run a "normal" session instead of a "micro" one. I mean we still obviously turn a lot of knobs off for the login screen, but we're running the same implementation inside the session as out, and we give the user a consistent experience and don't have to implement everything twice. > A successful login there would unlock the other session. This > microsession can be displayed on *some* output which depends on the > implementation of this process allowing to login. > The login session can also give hints to what sort of session this is > now transformed (pipewire or real, from your proposal below). This is > useful for apps/libs like spotify/pulseaudio as they can check if they > should output music on physical devices for example or not. So logind already tells a session whether or not it is active, and already handles giving and taking away devices from a session. These are things parts of the session can and do listen to today. --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hey, On Thu, 2020-04-16 at 14:45 -0400, Ray Strode wrote: > We don't really do a lot of this today, but one vision for the future is > something like this: Yup, something like that. I am really not sure about the details. 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. 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. While possible, I see the disadvantages that, 1. GDM/the greeter cannot know whether attaching is possible, 2. the user could try launching a different session type, and finally 3. we would likely get different implementations with varying degree of brokenness. So, if we made this a first level concept inside logind, then we suddenly get the flexibility to reconsider a lot of legacy design choices. Right now to login/create a session we do: * GDM starts helper process * Helper does pam authentication and creates pam session, * pam_logind moves helper into scope and attaches an FD for watching * Helper effectively launches the user's session processes 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 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. What could this mean? 1. Launching a graphical session becomes entirely the job of 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! 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. 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? Benjamin signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
Hi, On 4/16/20 8:45 PM, Ray Strode wrote: Hey, On Wed, Apr 8, 2020 at 12:04 AM Erik Jensen wrote: Chrome Remote Desktop currently works on Linux by spinning up its own Xvfb server and running a graphical session in that. However, as more and more parts of the stack assume that a user will have at most one graphical session, this is leading to more breakage more often. E.g., several distros have switched DBUS to using a single session bus per user, which only supports one graphical session, and recent versions of GDM will fail to log a user in locally at all if a Chrome Remote Desktop session is running due to https://gitlab.gnome.org/GNOME/gdm/-/issues/580. Given that Chrome Remote Desktop starts at boot, the latter means that even just setting it up and rebooting is enough to break local logins for the user, which is obviously less than ideal. Right, and as mentioned in the bug, GNOME doesn't really support logging in more than once with the same user from a data reliability point of view anyway. I mean the settings database doesn't work well if more than one thing is writing to it at the same time (which is one of the reasons writes for all apps are funneled through a daemon). We have the following constraints for our use case: * Chrome Remote Desktop must be usable after boot without the user needing to log in locally, first. makes sense. * It must be possible to "curtain" the session, meaning that, when a user is connected, their session is not displayed on the local monitor. (Imagine a user working from home and connecting to their workstation in a shared office space.) Yea this is something we've wanted in GNOME for a long. See for instance this bug from 2005: https://bugzilla.gnome.org/show_bug.cgi?id=311780 Back then we didn't even have compositing window managers so it wasn't something we could practically implement. Today's a different story! This is something mutter/gnome-shell can reasonably implement with some effort. I really like the idea of curtaining the session. However, i am wondering if logind couldn't serve there as sort of gatekeeper, this idea is not new, i was thinking about that already a few years ago. The idea is that a session in logind can be locked or unlocked. In case it is locked, logind would spin up a "micro" session with a process that renders something to login. A successful login there would unlock the other session. This microsession can be displayed on *some* output which depends on the implementation of this process allowing to login. The login session can also give hints to what sort of session this is now transformed (pipewire or real, from your proposal below). This is useful for apps/libs like spotify/pulseaudio as they can check if they should output music on physical devices for example or not. GNOME would then be told by logind when it needs to transform to a different sort of session. I think this is useful to have in logind instead of gdm / gnome itself, because the process of login in / bringing up a session is more unified.There is no need to differentiate between login from something like chrome or the physical appearance of a person in front of a screen. Additionally, it seems to me that this is more crash proof, if the session crashes because of something, a user would just be thrown back to the micro session, hopefully leaving him to login back. Greetings, bu5hm4n * It's okay to require X11 today, but there should be a reasonable path forward as more distributions switch to Wayland. I think it's more likely for mutter, that this would land in the native display server (wayland) side first. Possible idea brainstorming: I'm hoping for feedback for the feasibility of these, given I don't have a lot of experience with Wayland or the modern graphical session architecture. All of these have gaps which make them likely not usable *right now*, so the question is probably which approach would be the most likely to be accepted by the relevant projects, and potentially which would be the quickest to design and get working. There's likely other possibilities that I haven't thought of. [snip] ~Add curtaining support to session compositors~ This seem like the most plausible way forward. So the original idea with having a user bus instead of a session bus was that e.g., gnome-shell would handle all sessions, not just one session. So rather than a gnome-shell per session, there would be just the one for the user, started by systemd and running in its own cgroup. (Likewise, dconfd would handle setting writes for all sessions, and then no worries about the settings database getting corrupted.) The idea is, that if gnome-session is started in the mode that tells it to use systemd, rather than starting gnome-shell and the rest of the required components of the session itself, it instead defers to the user's systemd instance to reach a specific target. That target has various session services as dependencies in
