Re: Chrome Remote Desktop and Wayland
Thanks all for the discussion so far. The discussion of how things might work for gnome-remote-desktop included calls to, e.g., org.gnome.Mutter.RemoteDesktop.CreateSession, org.gnome.Mutter.RemoteDesktop.CreateOutput, and org.gnome.Mutter.ScreenCast.CreateSession. Ideally, Chrome Remote Desktop wouldn't need specific knowledge of each desktop environment, but could rather use a standard mechanism to enumerate installed session types that support curtained remote usage (using .desktop files?) and initiate a remote session in a standard way, including setting up the virtual display and doing input injection. Either way, this sounds like a longer-term solution. To attempt to effect some improvement in the shorter term, we've been discussing the possibility of using our own compositor (possibly an adapted version of Weston) that supports both remote access and attaching to the console. By default, it would run in the background, but we'd install our own "Connect to local Chrome Remote Desktop session" wayland session that, when selected from the display manager, resulted in the session being attached to the local display. Initially, we'd only support X session types (same as today) by using Xwayland, but we could potentially support running nested wayland sessions in the future using subsurfaces. (This would again require some way to identify which session types supported nesting.) My gut reasoning would be that it would be easier for a lightweight compositor to implement nesting than multi-output curtaining support, so this mode might be useful even in the future when the major desktop environments have their own built-in remote desktop support, but, not having implemented a compositor, I couldn't say for sure. Does that sound reasonable? Or is efficient nesting support unlikely enough to happen in any compositor / desktop environment that this would be a dead end, and we'd be better off hacking together a temporary solution for forwarding frames from Xvfb to the local console if that's a feature we want to support, and otherwise waiting for remoting desktop support to land in the various Wayland-based desktop environments? Thanks! ___ 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 Thu, Apr 23, 2020 at 2:27 AM Jonas Ådahl wrote: > Can't the remote login session still be "wayland", but without being > able to be drm master? So I think you're saying: "Clients still speak the wayland protocol when talking to the display server even if they're getting displayed via pipewire, so they should still have a wayland session type." It's a valid point that the possible session types are named after display server protocols, not display server outputs. i.e., we have "x11" and "wayland" not "x11-over-kms" and "wayland-over-kms". Although it all gets muddy when you consider mir supports wayland protocols, and even wayland supports x11 protocols with Xwayland, etc. > We still need API to manage the pipewire streams > (add/remove/change virtual outputs, So in my proposal, I said a virtual output can be automatically created when the logind session is registered, and all windows can be moved to that output when the session switches from "online" to "active" state (and we'd add some way for logind to be able to be told to move from "online" to "active" in this new session type when a user connects) > inject input, So this point here is a strong reason not to have a session type named "pipewire". And it's not something I'd considered before. I mean input isn't going through pipewire. And, of course, even getting the pipewire stream needs to go through mutter. I guess pipewire isn't really first class, or distinguishing here. So you've convinced me. > would adding a new session type bring us anything useful? Well, it would be useful if we had some logind level bookkeeping that distinguish e.g., vnc sessions from drm ones. but I guess session type isn't going to work out for that purpose. Maybe, sd_session_get_service is good enough for that purpose, then. logind sessions are generally registered with pam_systemd anyway, so there's going to be an associated pam service file. If we decide it's not good enough, we could always try to add a sd_session_get_output_target (render_platform/medium/whatever) > We wouldn't just implicitly spit out a > pipewire stream for some made up output, I assume we still want it to be > managed some how by the remote desktop service. Okay, so let's do another iteration, and talk this through this updated vision a little deeper but from the gnome-remote-desktop point of view. I assume chrome-remote-desktop would be similar but let's start with g-r-d. If this is TL;DR territory let me know and I'll throw it on the GNOME wiki instead. Here's how I believe gnome-remote-desktop works *today* with a shared local session instead of a curtained local session: 0. User logs in from the GDM login screen on VT 1. This opens a pam session, registers a logind session, and runs gnome-session 1. gnome-session starts the session off by doing: $ systemctl --user start gnome-session-wayland@gnome.target where "wayland" is the session type (the @gnome part isn't important for this discussion, but it could also be "@gnome-classic" for classic mode or "@gnome-login" for the login screen). 2. This target pulls in gnome-shell-wayland.service which starts gnome-shell. 3. Gnome-shell initializes its "native" backend where it sets up kernel modesetting. It uses the graphics hardware attached to seat0. If the oldest graphical session isn't attached to seat0, gnome-shell will fail to initialize. This logic will obviously need to be improved. 4. The gnome-session-wayland target also pulls in gsd-sharing.service which starts the daemon that starts gnome-remote-desktop. This is guaranteed to be started after gnome-shell is started. 5. gnome-remote-desktop tells mutter it's going to be doing input remotely by calling org.gnome.Mutter.RemoteDesktop.CreateSession. This makes mutter set up virtual input devices, and provides access to those input devices via a unique identifier. 6. gnome-remote-desktop tells mutter it's going to be doing output remotely by calling org.gnome.Mutter.ScreenCast.CreateSession. It links that output to the previously set up virtual input devices by passing the unique identifier generated in step 5 to this call. 7. gnome-remote-desktop tells mutter to send the primary monitor of the already running session to the newly created screencast session by calling org.gnome.Mutter.ScreenCast.Session.RecordMonitor. This call returns a pipewire stream, with one end hooked up to the primary monitor of the already running session. 8. gnome-remote-desktop acts as a VNC server and forwards all input from VNC clients to mutter via the virtual input devices created in step 5. It pushes video from the pipewire stream created in step 7 to VNC clients. I think I got those steps right, but tell me if you spot anything I got wrong. :-). Now how would gnome-remote-desktop go from here to a world with curtaining? 0. We're no longer going to have one session that gets shared, so we need two distinct sessions registered. One session is still the user logging in
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 22, 2020 at 04:34:01PM -0400, Ray Strode wrote: > Hi, > > On Tue, Apr 21, 2020 at 8:21 AM Benjamin Berg wrote: > > 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. > why does that information need to be conveyed? who would consume it? > > > > 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. > So to be clear, I've been advocating for mutter/gnome-shell to do the > attaching *themselves*. We don't need any new api for them to do > that. > > If mutter is already running, it just needs to set up a sd_login_monitor > to detect when a new session for the user show up. As soon as a > new session is registered with logind, that new session is announced. > > mutter can then check the session type of the newly registered session > and see if it needs to add a new output (to e.g. pipewire or to kms). > > This can be done using api that exists today (well we need a new > session type, right now there's only tty, x11, wayland, mir, unspecified, > we need pipewire too) Can't the remote login session still be "wayland", but without being able to be drm master? We still need API to manage the pipewire streams (add/remove/change virtual outputs, inject input, i.e. something like org.gnome.Mutter.RemoteDesktop/ScreenCast); would adding a new session type bring us anything useful? We wouldn't just implicitly spit out a pipewire stream for some made up output, I assume we still want it to be managed some how by the remote desktop service. Jonas > > > 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. > Right, mutter shouldn't be guessing which session to use. it should use > all of them! it may use some logic to figure out where window go (e.g, > last that went active wins), but all active sessions should get chrome. > > > 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. > Totally agree with these words, but I also think that's precisely what a > "user" is in logind. i don't see any advantage to having something between > user and session that's basically the same as user. > > > Sorry, I meant the desktop here. > ah okay. > > > 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. > You're saying a user wants to log into KDE on X11 and GNOME on wayland > at the same time, and both use systemd --user? > > First, I think that's a fairly niche use case that cause problems for the user > (e.g., what if they try to run firefox in both?) > > But I don't think there's anything that would prevent it from working. > > logind lets a display server query whether or not a session is KDE or GNOME. > See sd_session_get_desktop . Each display server, should clearly only > manage sessions registered for their own desktop. > > > > > 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. > I still don't understand. Is this in the context of KDE and GNOME ? > > --Ray > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ 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 Tue, Apr 21, 2020 at 8:21 AM Benjamin Berg wrote: > 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. why does that information need to be conveyed? who would consume it? > > 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. So to be clear, I've been advocating for mutter/gnome-shell to do the attaching *themselves*. We don't need any new api for them to do that. If mutter is already running, it just needs to set up a sd_login_monitor to detect when a new session for the user show up. As soon as a new session is registered with logind, that new session is announced. mutter can then check the session type of the newly registered session and see if it needs to add a new output (to e.g. pipewire or to kms). This can be done using api that exists today (well we need a new session type, right now there's only tty, x11, wayland, mir, unspecified, we need pipewire too) > 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. Right, mutter shouldn't be guessing which session to use. it should use all of them! it may use some logic to figure out where window go (e.g, last that went active wins), but all active sessions should get chrome. > 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. Totally agree with these words, but I also think that's precisely what a "user" is in logind. i don't see any advantage to having something between user and session that's basically the same as user. > Sorry, I meant the desktop here. ah okay. > 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. You're saying a user wants to log into KDE on X11 and GNOME on wayland at the same time, and both use systemd --user? First, I think that's a fairly niche use case that cause problems for the user (e.g., what if they try to run firefox in both?) But I don't think there's anything that would prevent it from working. logind lets a display server query whether or not a session is KDE or GNOME. See sd_session_get_desktop . Each display server, should clearly only manage sessions registered for their own desktop. > > > 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. I still don't understand. Is this in the context of KDE and GNOME ? --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 Tue, 21 Apr 2020 at 14:21:39 +0200, Benjamin Berg wrote: > 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. FWIW, the session bus integration in dbus refers to a "user-session" (a user, in systemd-logind terms) consisting of one or more concurrent "login sessions" (a session, in systemd-logind terms). I borrowed the "login session" terminology from PAM, because I wanted a slightly longer term than systemd's "session" - partly to be able to disambiguate exactly what I was talking about, and partly because "session" already means something a bit more abstract and undefined in D-Bus. The use of "user" in systemd-logind is a little confusing, because you'd naturally expect everyone in /etc/passwd to be considered a "user" - but systemd-logind is a login manager, not a uid manager, so users who are not currently logged in don't exist as far as systemd-logind is concerned. If you can come up with better terminology for this, I'm happy to steal it for dbus :-) > 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 > [long] as any of the underlying logind sessions are active. You can already do this, client-side, by aggregating information from all of the login sessions that make up the user-session, if you want to. There is no privilege separation between login sessions that share a uid (and on practical systems they can all control each other by rewriting each other's configuration files, using D-Bus to tell each other to execute arbitrary code, or sometimes even ptracing each other), so there seems little point in having any policies of the form "only processes belonging to an active login-session can do xyz". Instead, I think the way to think about it is "only processes owned by uids that have at least one active login-session (and possibly some inactive ones) can do xyz". For example, that means that if I have access to something as a result of being the current active user (Wayland, X11 or or login/getty/bash on the foreground virtual terminal), I should be able to get exactly the same access by ssh'ing into that machine from another one, or by having one of my cron jobs run - but then when I log out on the console, or when I switch between VTs, my ssh sessions and cron jobs also lose that privilege. Sandboxed apps (Flatpak, Snap, etc.) should have less access than apps that are in the desktop session's trusted computing base, but they normally exist in the same login session as the trusted computing base *anyway*, so the place to impose a privilege boundary is in the sandboxed app framework, rather than between login sessions. smcv ___ 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 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
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
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
Re: Chrome Remote Desktop and Wayland
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. > * 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 including gnome-shell. Crucially, if one gnome-session instance starts gnome-shell via a systemd user service (say via chrome remote desktop), and another gnome-session instance gets started in a new session (say via the local gdm login screen), and also tries to set a systemd --user target that brings in gnome-shell, systemd won't start gnome-shell twice. gnome-shell is instead a sort of factory process that starts when the first session logs in and lasts until the last session logs out. But if gnome-shell is a factory process that may be around before a session is started, how can it know when that new session comes around so it can "adopt" or service it? Sessions are registered with logind (usually via pam_systemd, but there's an underlying D-Bus api too). gnome-shell can easily ask logind to enumerate all the sessions that belong to a user (see sd_uid_get_sessions), and can also easily detect when a new session comes or goes (see sd_login_monitor). It can also detect when a session is active or inactive via logind. We don't really do a lot of this today, but one vision for the future is something like this: - User logs into their workstation at work and hacks away for a while before needing to leave. - Before going the user enables remote desktop, which leads to the new session getting registered with logind . - This, in turn, tells systemd --user to reach a particular target that pulls in gnome-shell,
Re: Chrome Remote Desktop and Wayland
On Thu, 9 Apr 2020 12:05:57 -0700 Erik Jensen said: > On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl wrote: > [snip] > > DRM master and input device revocation should be handled more or less > > already by most if not all compositors, by closing devices, by then > > going dorment until access is returned to the compositor. I don't know > > if there is any compositor that can already handle continuing it's > > session headless with an active PipeWire stream. > > Ideally, (though not a strict requirement for us), there'd also be a > way to specify the resolution of the offscreen virtual display (to > match the resolution of the client) without modifying the modes used > locally once the session is switched back to the local display(s). > > [snip] > > More or less, yes. Launching sessions without DRM master and going > > headless is probably things we can add capability fields for in the > > session .desktop files, and show dialogs like "Wait" or "Terminate > > session" if a conflict appears (as mentioned in the linked GDM bug). All > > of this would also not need be specific to a certain windowing system, > > so that you we can use the same APIs for handling both Wayland sessions, > > X11 sessions, and whatever more types that may eventually appear. > > You mentioned that integration with session management makes sense to > discuss with display manager folks. Where would be the best place to > discuss other such potential cross-windowing system remote-desktop > APIs like .desktop fields or headless startup? my take is this should be a daemon like a hybrid login manager/sshd, but instead of a text login shell, it authenticates then launches a "virtual fb" parent compositor that sets up a wayland compositor "rendering to ram" and then launches the actual user session as a wayland client. this will require compositors that are compatible need to support targeting both drm/kms directly in the tty AND as a wayland client of this compositor. this compositor would probably use something like the wayland fullscreen shell. it would be this compositor that encodes and transmits the compositing results over the network as well as reading in input from the remote system. the dbus session problem just need working around probably with another dbus session bus launched for this session and if apps have a problem with being run multiple times with different dbus sessions on the same system/homedir.. well.. there is nothing to be done - it's a problem with that app. it only matters if the user is logged in on the console and remotely and uses one of these types of apps. they can opt to not use them or do that, or these apps get fixed. if they want to "take over their existing console login session" the same idea applies but this remote compositor is actually a full system-wide fullscreen compositor and can auth some user then redirect their on screen session to be remote (and issue appropriate monitor reconfiguring when this happens) and replace their on-console session with a picture of a horses behind until the remote session ends... the same daemon can do both just with the option of it being a system-wide console compositor as opposed to "virtual, only for remote clients" most of the code is the same/shared. then they will bypass the above singleton problem apps by having only a single login (gui one) and single dbus session. the takeaway from this is more that the ecosystem at large needs to support compositors running as wayland clients with a system compositor using a fullscreen shell with all the appropriate logic to handle real local screens and expose them and let the client compositor configure them, as well as doing the "virtual rendering to memory and fake a virtual screen and modify that one (or ones if you want multiple screens) by unplugging/plugging it with new resolution options etc. if this system compositor is fairly lean and efficient and essentially doesn't get in the way of real desktop compositors, then it probably will be supported by most major compositors eventually. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl wrote: [snip] > DRM master and input device revocation should be handled more or less > already by most if not all compositors, by closing devices, by then > going dorment until access is returned to the compositor. I don't know > if there is any compositor that can already handle continuing it's > session headless with an active PipeWire stream. Ideally, (though not a strict requirement for us), there'd also be a way to specify the resolution of the offscreen virtual display (to match the resolution of the client) without modifying the modes used locally once the session is switched back to the local display(s). [snip] > More or less, yes. Launching sessions without DRM master and going > headless is probably things we can add capability fields for in the > session .desktop files, and show dialogs like "Wait" or "Terminate > session" if a conflict appears (as mentioned in the linked GDM bug). All > of this would also not need be specific to a certain windowing system, > so that you we can use the same APIs for handling both Wayland sessions, > X11 sessions, and whatever more types that may eventually appear. You mentioned that integration with session management makes sense to discuss with display manager folks. Where would be the best place to discuss other such potential cross-windowing system remote-desktop APIs like .desktop fields or headless startup? Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 08, 2020 at 11:17:14AM -0700, Erik Jensen wrote: > On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl wrote: > > Either multiple separate units (e.g. GDM and Chrome Remote Desktop login > > manager) needs to both try to manage the same sessions via logind, which > > sounds fragile and unlikely to be able to cope with the various security > > policies mentioned above; or an session management API, using the D-Bus > > system bus, needs to be added and implemented by the relevant display > > managers. This API would need to handle things like opening headless > > sessions without making them DRM master; handing over control of a > > headless session if the session is supposed to be turned into a local > > one, then hand it back etc, with all the various policy related to e.g. > > when to show the lock screen or not taken into account. > > It sounds like this would require a few new pieces: > * The session management API you mentioned for coordinating sessions. > * Compositor support for launching without DRM master. > * Compositor support for offscreen rendering when DRM master is > revoked. (Presumably grant and revocation of DRM master is already > handled due to VT switching? Do any compositors already support this > if there's an ongoing PipeWire capture when they are put in the > background?) DRM master and input device revocation should be handled more or less already by most if not all compositors, by closing devices, by then going dorment until access is returned to the compositor. I don't know if there is any compositor that can already handle continuing it's session headless with an active PipeWire stream. > * A solution for input injection. > > A remote desktop tool like Chrome Remote Desktop would then be > responsible for using the new API to launch a new session without DRM > master or revoke DRM master from an existing session (presumably > returning the local display to the login screen), and then connecting > to the appropriate Wayland session to initiate video capture and input > injection. > > Does that accurately reflect your suggested solution? More or less, yes. Launching sessions without DRM master and going headless is probably things we can add capability fields for in the session .desktop files, and show dialogs like "Wait" or "Terminate session" if a conflict appears (as mentioned in the linked GDM bug). All of this would also not need be specific to a certain windowing system, so that you we can use the same APIs for handling both Wayland sessions, X11 sessions, and whatever more types that may eventually appear. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl wrote: > Either multiple separate units (e.g. GDM and Chrome Remote Desktop login > manager) needs to both try to manage the same sessions via logind, which > sounds fragile and unlikely to be able to cope with the various security > policies mentioned above; or an session management API, using the D-Bus > system bus, needs to be added and implemented by the relevant display > managers. This API would need to handle things like opening headless > sessions without making them DRM master; handing over control of a > headless session if the session is supposed to be turned into a local > one, then hand it back etc, with all the various policy related to e.g. > when to show the lock screen or not taken into account. It sounds like this would require a few new pieces: * The session management API you mentioned for coordinating sessions. * Compositor support for launching without DRM master. * Compositor support for offscreen rendering when DRM master is revoked. (Presumably grant and revocation of DRM master is already handled due to VT switching? Do any compositors already support this if there's an ongoing PipeWire capture when they are put in the background?) * A solution for input injection. A remote desktop tool like Chrome Remote Desktop would then be responsible for using the new API to launch a new session without DRM master or revoke DRM master from an existing session (presumably returning the local display to the login screen), and then connecting to the appropriate Wayland session to initiate video capture and input injection. Does that accurately reflect your suggested solution? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, 08 Apr 2020 at 11:02:36 +0200, Jonas Ådahl wrote: > With that being said, it is possible to run multiple D-Bus sessions, > where session busses are separate - it's just that noone actually does > it as even if you have separate D-Bus sessions, separate > $XDG_RUNTIME_DIRs, the sessions still share fundamental resources such > as $HOME, and it is very likely that many applications you attempt to > run will run into issues where they, running on separate "sessions" on > the same user, will try to manage the same set of files in > the users home directory. We tried this: for about the first decade of D-Bus' existence, the most common model was one session bus per X11 display (with dbus-launch, sometimes packaged as dbus-x11). In practice, it didn't work very well except in the trivial case where there is exactly one X11 session at a time, and I now recommend doing something else. The Mozilla family of browsers, which want to have a single instance per home directory, are a common pain point. Because we have been careful to keep backwards compatibility, recent versions of the reference implementation of D-Bus expect an OS integrator to decide what "session" means to them (or perhaps delegate that decision to the sysadmin). If the semantics they choose result in two instances of an application overwriting each other's files, D-Bus does not have an answer to that, other than "perhaps you should have chosen differently". These models are ready-made and already work: - one D-Bus session bus per "user-session", using $XDG_RUNTIME_DIR/bus (my recommendation; dbus-user-session package in Debian) - one D-Bus session bus per X11 display, by setting a separate $DBUS_SESSION_BUS_ADDRESS and some magic root window properties for each one (historical behaviour; dbus-x11 package in Debian; expect to see applications overwriting each other's changes) and these are something you could put together from pieces by arranging for $DBUS_SESSION_BUS_ADDRESS to be set appropriately, for example by using dbus-run-session(1) or starting a dbus-daemon(1) yourself, if they're what you want: - one D-Bus session bus per Wayland display - one D-Bus session bus per (PAM) login session - one D-Bus session bus per just about anything else with a defined lifetime See https://lists.freedesktop.org/archives/dbus/2015-January/016522.html for what I mean by "user-session" - I'm using it as a jargon term here because I'm not aware of any other name for this concept. Non-reference implementations of D-Bus, like dbus-broker, might have a more opinionated definition of what a session means, and decline to operate in situations that they were not designed for. That's their maintainers' design choice. > even if you have [...] separate $XDG_RUNTIME_DIRs Note that (unlike D-Bus) the freedesktop.org Base Directory specification specifically defines XDG_RUNTIME_DIR to be one per what I call a "user-session" above. For example, if you are concurrently logged in with uid 1000 using gdm on tty1, getty on tty2, a ssh session and a remote desktop, according to the specification they must all share a XDG_RUNTIME_DIR. If you have more than one distinct XDG_RUNTIME_DIR for the same uid, then you are not implementing the Base Directory specification, and you might find that libraries and applications that were expecting XDG_RUNTIME_DIR to be an interoperable Base Directory implementation (including D-Bus implementations!) don't work as intended. In this case you get to keep both pieces. This is presumably why Wayland has $WAYLAND_DISPLAY, so that in the common case you have a single Wayland compositor "wayland-0" per XDG_RUNTIME_DIR, but in rarer cases (like debugging in a nested compositor), you can have more than one compositor and tell your application to choose a non-default one. smcv ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Chrome Remote Desktop and Wayland
On Wed, Apr 08, 2020 at 07:07:19PM +1200, Scott Anderson wrote: > On 8/04/20 4:04 pm, Erik Jensen wrote: > > Hello, > > > > I'm currently looking into how best to continue supporting Linux for > > Chrome Remote Desktop given the current direction of development for > > graphical sessions on Linux, and would like some community feedback as > > to the best path forward. > > > > 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. > > This point about Gnome breaking multiple sessions has been a pain point for > us (sway/wlroots), and why we typically push back against D-Bus solutions to > Wayland problems, at least on the session bus. Wayland itself works > perfectly fine with multiple sessions, and is something we want to preserve. > > It may be possible to create individual session buses for each login > session, but I don't know how this works in practice and I don't think > anybody currently does it. The dependency on a functional D-Bus session bus is in practice a necessity in a modern desktop environment today on Linux; it would be counter productive to try to avoid solving any possible issues related to it to run multiple separate sessions, since so much is using it. For example anything using GtkApplication or GApplication will use the session bus, anything related to accessibility uses D-Bus (although on its own bus), any sandboxed appliction using the portal APIs (including properly sandboxed flatpak and snap applications) will use the session bus, desktop notifications uses the session bus. With that being said, it is possible to run multiple D-Bus sessions, where session busses are separate - it's just that noone actually does it as even if you have separate D-Bus sessions, separate $XDG_RUNTIME_DIRs, the sessions still share fundamental resources such as $HOME, and it is very likely that many applications you attempt to run will run into issues where they, running on separate "sessions" on the same user, will try to manage the same set of files in the users home directory. Thus, the only way to get reliable truly parallel sessions is to use separate users, or separate $HOME directories, where the two sessions do not share any managed resources at all. Whether there is a point in using the same user with separate $HOME directories is desired I doubt. > > > 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. > > * 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.) > > * When the user disconnects, the session must be locked in some > > manner so a person at the local machine can't take over the session > > without authentication. > > * It's okay to require X11 today, but there should be a reasonable > > path forward as more distributions switch to Wayland. > > * It would be nice, though not required, if the user could access the > > same session remotely as they see locally. (Though, as noted above, > > having two separate sessions seems to be explicitly not supported by > > many new developments, so this may be effectively required.) > > * It would be nice, though not required, if the session could be > > resized to fit the client display when the user is connected remotely. > > * It would be nice, though not required, if apps in the session could > > have access to graphics acceleration when accessed remotely. > > > > 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. > > > > ~Use a nesting compositor~ > > This involves having an outer compositor that we control that
Re: Chrome Remote Desktop and Wayland
On 8/04/20 4:04 pm, Erik Jensen wrote: Hello, I'm currently looking into how best to continue supporting Linux for Chrome Remote Desktop given the current direction of development for graphical sessions on Linux, and would like some community feedback as to the best path forward. 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. This point about Gnome breaking multiple sessions has been a pain point for us (sway/wlroots), and why we typically push back against D-Bus solutions to Wayland problems, at least on the session bus. Wayland itself works perfectly fine with multiple sessions, and is something we want to preserve. It may be possible to create individual session buses for each login session, but I don't know how this works in practice and I don't think anybody currently does it. 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. * 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.) * When the user disconnects, the session must be locked in some manner so a person at the local machine can't take over the session without authentication. * It's okay to require X11 today, but there should be a reasonable path forward as more distributions switch to Wayland. * It would be nice, though not required, if the user could access the same session remotely as they see locally. (Though, as noted above, having two separate sessions seems to be explicitly not supported by many new developments, so this may be effectively required.) * It would be nice, though not required, if the session could be resized to fit the client display when the user is connected remotely. * It would be nice, though not required, if apps in the session could have access to graphics acceleration when accessed remotely. 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. ~Use a nesting compositor~ This involves having an outer compositor that we control that renders to the local screen when used locally, and handles curtaining, offscreen rendering, video capture, and input injection when used remotely. It would run X11 sessions via a fullscreen XWayland in rooted (not rootless) mode, and a Wayland session in nested mode. This would need some integration with the display manager so that logging in locally would bring the session to the local display and disconnect the remote connection. Similarly, connecting remotely would need to return to the login screen and switch to off screen rendering. I don't know enough to know whether this is feasible, or whether the necessary GPU resource sharing is currently possible. Additionally, nesting Wayland sessions requires support from sub-compositor for nesting, which appears not to be ubiquitous, and generally requires a special command-line flag. This means support for Wayland sessions would have to be special cased if supported at all. That said, sticking to nested X11 sessions only would probably be tenable for now, assuming there is a future path forward for nested Wayland sessions in the future, and assuming the technical details of interacting with the local login manager could be figured out. ~Integrate with a system compositor~ I've seen some discussion of having a system compositor that runs from the boot splash to shutdown, and manages the display of each session (and even the console). This seems like an ideal place to install hooks that a tool such as Chrome Remote Desktop or an RDP server could use to provide remote access to the machine, including curtaining. This has the potential for a very integrated experience like RDP sessions on Windows.
