non-local D-Bus (was: New libgtop maintainer)

[Simon McVittie]

On 11/08/13 12:46, Jasper St. Pierre wrote:
> I think we've said that remote DBus is possible, but
> would take a considerable amount of work to actually get working.

Cross-posting to dbus@ for this reply since I don't think we've really
written this down anywhere.

Here is my opinion on remote D-Bus, as a D-Bus maintainer:

* The well-known session bus is local. If you don't mind everyone
  capable of spoofing TCP on your local LAN being privileged
  (possibly root-equivalent) on your machine, it is, or used to be,
  possible to share it over TCP, in conjunction with home directories
  shared via NFS or something. We don't intentionally break that
  configuration, but we don't test or support it either. It wouldn't
  surprise me if "more opinionated" projects like systemd *do*
  intentionally break non-local session buses at some point, and to be
  honest that would probably be a good thing for general system
  robustness.

* As far as I'm concerned, the well-known system bus (on Unix only) is
  local and always has been. If you want to access another system's
  system bus remotely, opening a ssh tunnel to something equivalent to
  socat is one sensible approach (I believe udisks remote management
  works like that).

* Non-standard buses (like the AT-SPI "accessibility bus") are designed
  by whoever sets them up; they get to say whether that bus is local,
  remote, or either-according-to-sysadmin-choice. I would recommend
  always-local. dbus.fd.o will not intentionally break non-standard
  buses, but we don't specifically test or support them either.

If you rely on non-local D-Bus, please be prepared to send us patches
when we accidentally break it. I would accept high-quality patches to
improve non-local D-Bus, but my top priorities are the well-known
session and system buses in a local-only configuration, as seen in
typical Linux distributions.

Regards,
    S