Chrome Remote Desktop and Wayland

[Simon McVittie]

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