Re: Chrome Remote Desktop and Wayland
Hi,
On Fri, 2020-04-17 at 11:00 -0400, Ray Strode wrote:
> 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".
Yes, I agree that "user" is very similar. However, it cannot currently
convey any information about whether a graphical session is already
running or whether it is capable of spanning multiple logind sessions.
> > 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)
Well, you need some mechanism to attach the new session/seat to the
running graphical session and then watch for it to be released again.
And yes, the session leader process could be the one taking care of
that.
Now, what I was thinking was that we could standardise how this works.
That shouldn't need much API, and I was hoping that the solution could
become nicer overall.
But, the other part of this is that the situation is confusing. Right
now we assign "user" processes to one of the logind sessions by doing a
best guess. That works great as long as the user has one graphical
logind session. But, if this graphical session starts spanning multiple
logind sessions, then the choice becomes more relevant as each of the
sessions might for example have a different "Active" state.
So, having something that represents the combination of all of them
could bypass that problem in an elegant way. We would never need to
"guess" the session, we would just always return the combined "user"
session. This user session would for example be considered "Active" as
lone as any of the underlying logind sessions are active.
> > 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.
Sure. What I mean is that GDM does not really know about the
capabilities of the session leader process.
I suspect that one could add sufficient information into the sessions
.desktop file though.
> > 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.
Sorry, I meant the desktop here. So if KDE and GNOME have incompatible
implementation then we may run into odd error scenarios should the user
try to change the session type while they are logged in already.
> > 3. we would likely get different implementations with varying degree
> > of brokenness.
> Not sure what you're saying here, can you reiterate?
I think the above captures it well enough.
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
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, 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
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
