Chrome Remote Desktop and Wayland

[Simon McVittie]

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