Chrome Remote Desktop and Wayland

[Ray Strode]

Hi,

On Fri, Apr 17, 2020 at 8:45 AM Benjamin Berg <bberg at redhat.com> wrote:
> I feel that this means that we conceptually have a "composite" session
> that consists of multiple "normal" logind sessions. And I wonder if we
> could make this singleton "composite" session an explicit concept
> rather than something that purely exists implicitly.
This concept of a "composite session" you speak of already exists in
logind. In logind nomenclature it's called a "user".

> In the "simple" implementation, we could expect each desktop
> environment to handle all this themselves. i.e. gnome-session would
> launch, see there is already an existing one, and then do an
> appropriate call to "attach" the new seat and remain dormant until it
> should/needs to be detached again.
I don't think gnome-session needs to do much beyond what it's already
doing.  It just needs to make sure systemd is told what services to
start, if they aren't already started (which target to reach)

> While possible, I see the disadvantages that,
>  1. GDM/the greeter cannot know whether attaching is possible,
GDM certainly can (and already does) know if the user already has a
running session.

>  2. the user could try launching a different session type
Launching different session types should be supported.  I mean, if the
user is already running a local kms ("wayland") session, and then
starts a "pipewire", mutter should detect and handle that.
I think it would even be possible in theory (though maybe hard in
practice with mutter, and of dubious value) to support "x11" and
"wayland" at the same time.

>  3. we would likely get different implementations with varying degree
>     of brokenness.
Not sure what you're saying here, can you reiterate?

> Right now to login/create a session we do:
>  * GDM starts helper process
right, we call that a "session worker"

>  * Helper does pam authentication and creates pam session,
right.

>  * pam_logind moves helper into scope and attaches an FD for watching
pam_systemd, but yea it should have been called pam_logind :-)
Right, and to be clear, this is where session registration happens.
 pam_systemd use's logind's dbus api to say "Here's a new
wayland session" or "here's a new Xorg session".

>  * Helper effectively launches the user's session processes
Yup, the session worker forks off the session from here, and sticks
around to tell PAM when the session is over, too.

> What if, instead, the user can only have one "composite" graphical
> session from GDMs point of view (which may not support multiple "real"
> sessions, e.g. in the case of X11).
>
> We can have calls in logind to manage such a composite session, i.e.:
>  * attach a new "real" logind session
>  * detach a "real" logind session
>  * create a new "composite" session with an existing "real" session
So I don't understand why attaching a session would be a separate step
from creating the session.  logind automatically attaches all new sessions
to the user ("composite session" in your nomenclature).  why wouldn't
you want it to continue to do that?

Is the point that you want to support multiple concurrent composite sessions
for a user?  If so, what if those concurrent sessions share services? All of
a sudden those services need to not only see what sessions they're in, but
also need to see what composite sessions they're in?

> Session creation itself could be delegated to systemd-logind. The funny
> thing is, that then GDM may never need to launch user processes. It
> would go through PAM for authentication, and then from there just call
> the "attach" or "create" method.
So historically, the reason things have been done the way they are, is
because PAM has these notions of credentials and environment that
PAM modules can influence.  The simplest example is
environment variables, which can be fairly easily transferred out from
the session worker, but there's also, for example, creating a session
specific kernel keyring, assigning supplementary groups, instituting
ulimits, etc.  Basically the PAM modules can do blackbox things to the
the process running the pam conversation  and expect those "things" to
get passed on to the children of that process, to the session getting
opened.

Btw, PAM also expects, in some cases to be able to update those "things"
at unlock time.  A canonical example would be a kerberos ticket put on
the session keyring. The ticket gets assigned at login, and renewed when
the user types their password at the unlock screen.  In order to make that
sort of thing work, GDM jumps through some contortions to make the
session worker used for unlocking  be forked from the session worker
used for login. (Though these days kerberos tickets aren't put on the
session keyring).

Now in a world where most of the session is running from a user context
anyway, obviously the users session, today, isn't picking up all those things.

This has created some problems, for instance,

https://bugzilla.gnome.org/show_bug.cgi?id=780622

But, that just means we need to change how those "things" (limits, credentials,
resources, environment, whatever) are imposed on the user's processes.

It's something we need to fix on an as needed basis, basically.

Anyway, that's a long winded way of me saying, there is a reason it was
done the way it was, and there are implications to changing it. Whether
it's worth doing anyway, is a different question, of course.

> What could this mean?
>
>  1. Launching a graphical session becomes entirely the job of logind
So is the idea that logind starts parsing /usr/share/xsessions,
/usr/share/wayland-sessions files, or we ditch those and switch purely
to systemd targets ?

Or, in this model,  are we sending what to execute straight to logind?
>  2. GDM could solely create dummy sessions (for authentication), and
>     delegate the rest to logind.
>  3. The dummy sessions could probably be stripped down to returning
>     an FD, they may not even need a persistent process/scope anymore.
>  4. Control over the session's environment is removed from the display
>     manager.
>     Please, let's stop passing around environment variables!
I'm all for easing our way off environment variable dependence, we just
have to make sure we don't break stuff in the process...

>  5. X11 sessions requiring Xorg might be interesting. Could work by
>     still letting GDM start Xorg in the original session, or
>     standardising a procedure on the logind side.
So Xorg these days runs as the user instead of as root, so there's no reason
in theory it couldn't be fixed to run from systemd service files instead of from
getting launched in the session by gdm-x-session.

I think I even wrote code for it once a long time ago:

https://cgit.freedesktop.org/~halfline/xserver/commit/?h=wip/logind-integration&id=f02bae74d10fd8fccb69de61014fdb3b3f26efce

> I am sure what I am proposing here is potentially a huge pain for e.g.
> flickerfree operations. But maybe letting logind start the user's
> session is not completely crazy and could actually lead to a much
> cleaner model overall?

So I don't think it would cause a problem wrt to flicker, but I'm not sure
the model is so much cleaner than status quo that it's worth the substantial
effort to implement.

I think the logind architecture that exists *today* is good enough to meet
our needs (with maybe minor changes that don't affect the general
architecture), so I'm a little apprehensive about changing it drastically.

Anyway, such changes would need run through systemd-devel, of course.

But, I really think, from a GNOME perspective, we can get a remote desktop
that does the curtaining, and works with systemd --user with very little changes
to logind (just the ones I mentioned in my last mail).

--Ray