[systemd-devel] Questions regarding dbus started via systemd --user

[Simon McVittie]

On 08/01/15 16:03, Dimitri John Ledkov wrote:
> There is upstart --user spawned per session, and everything is under
> it. The sessions' logind cgroups are parent of all processes within a
> session, and there are sub cgroups as needed for contained
> jobs/processes. Thus for three graphical sessions, one has three
> upstarts running, three dbus (with different bus ids), etc.
> 
> Thus my expectation would be to have a systemd (dbus, etc...) --user
> per-session/per-seat, rather than per-uid.

This is a conversation about the distinction between a per-(uid,machine)
bus (the "user bus") and a per-login-session bus (the "session bus").
We've had this discussion several times in the past, although perhaps
not involving you personally. I'll follow-up with some "further reading"
links about session bus vs. user bus, but freedesktop.org's mail
archives are a bit of a labyrinth so I wanted to get this sent off
before going looking for the right historical threads.

The "session bus" philosophy is how the D-Bus session bus was designed
to work around a decade ago. It's a consistent conceptual model (...
ish), but it breaks down as soon as you want to do something like leave
a headless Rygel service running after you log out, or interact with
your X11 session's D-Bus services from a ssh or getty login.

It also means you can't use D-Bus names as single-instance mutexes to
avoid "last write wins, earlier writes are lost" (or worse!) data
corruption in the home directory, because it allows more than one D-Bus
session to share a home directory, even in the absence of NFS or
whatever. This was meant to be one of the uses of D-Bus name ownership
semantics, so it's a pity that it has never worked in the general case.

Finally, there is no canonical list of the situations that the session
bus does and doesn't support, so whenever someone raises a bug or
feature request about one of the corner cases, nobody knows whether it's
a bug or a feature request or just wrong. Typical corner cases include:

* I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1
  and log in at the getty. How do I communicate with X11 session things
  over D-Bus, perhaps to disconnect from Telepathy without losing
  messages?
* The same, but I ssh in from another machine instead. Same question?
* I'm in an X11 session on aardvark, and I open a terminal
  emulator and do "ssh -X badger", then run an app on badger.
  For session bus purposes, is it part of my login session on aardvark,
  a new login session on badger, an existing login session on badger,
  or what? Why?
* The same, but I shared my home directory via NFS.
* The same, but I shared my home directory via NFS, and configured
  dbus-daemon to be available over TCP (yes, this is apparently
  something that is meant to work).
* I run "su". In the su shell, I run an app that wants to connect to
  the D-Bus session bus. Does it connect to my existing session bus,
  a new session bus for root, some existing session bus for root,
  or what? Why?
* I run "su -". Is it the same as "su"? Why/why not?

In response to concerns like those, various people have promoted the
"user bus" as a replacement for the session bus, or occasionally as a
second parallel bus. Where the session bus is per (uid,login session)
and the system bus is per-machine, the user bus is per (uid,machine).

I personally think having only the user bus (and having
(G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
because it's easy to understand and does not try to impose isolation
between sessions that are not actually a privilege boundary (same uid,
can ptrace each other, etc.).

Having only the session bus (as we do in e.g. Debian 8) is the next best
thing; it's at least an internally consistent model, even if it does
have a bunch of stupid corner cases.

I think having a session bus *and* a parallel user bus, which some
people have advocated in the past, is worse than having only the session
bus and should be avoided, because message order is not preserved
between distinct buses, and application authors shouldn't be required to
deal with IPC that happens in a non-deterministic order.

As far as I understand it, systemd's kdbus userland is intended to
support a system bus (the equivalent of dbus-daemon --system) and a user
bus, but there is no intention to support traditional session buses,
because the people writing systemd's D-Bus-related code are among those
who think the user bus is the way forward.

Regards,
    S