Session bus vs system bus for an embedded system

[Simon McVittie]

On Wed, 18 Apr 2018 at 10:55:28 +0200, Alan Martinovic wrote:
> Given the issues and the nature of the system,
> I kind of assumed it makes sense to
> ignore the session bus and just base everything
> on the system bus.

This is probably true. Because the system bus is a shared resource for
the whole system, you will need to set up some sort of security model
that matches your security policy (which uids can own which names, which
uids can send which messages, etc.).

If everything runs as uid 0, or if everything runs as a single nonzero
uid with no privilege separation, then you can probably apply a very
simple security policy where that uid can own all names and send all
messages.

Tools like dbus-monitor default to the session bus (because it's the
common case, and the only one you can debug without root privileges)
but can be directed to the system bus with a --system option. Similarly,
sample code will normally use the session bus, but it should be easy to
divert it to the system bus (for example by changing Gio.BusType.SESSION
to Gio.BusType.SYSTEM in PyGI-based code).

> Is there value in getting the session bus working
> an use it instead of a system bus for a single user
> embedded system?

Probably only if you are reusing existing session-bus services
(PulseAudio, Tracker, MPRIS, that sort of thing) which are not designed
to use the system bus.

> It's a GUI-less, headless system that developers
> access via UART or SSH, and physical users never
> access directly.

If you want a session bus on such a system, you will have to arrange
to have one yourself, either by using the systemd user service,
dbus-run-session(1), dbus-launch(1), or starting dbus-daemon the hard way.
https://lists.debian.org/debian-devel/2016/08/msg00554.html has an
overview of the various ways you might get a session bus.

If your device boots using systemd then I'd recommend making
`systemd --user` responsible for starting your user's session bus,
probably in conjunction with `loginctl enable-linger $username` to get
`systemd --user` started during boot.

The error message that you saw (involving a $DISPLAY for X11) is
libdbus failing to use its last-resort mechanism to get a dbus-daemon
("autolaunching"), which relies on X11. On a properly-set-up system,
that code path should never be necessary or reached.

    smcv