Dbus multi-machine behavior

[David Zeuthen]

Hi,

On Tue, Nov 2, 2010 at 11:36 AM, Miller, Douglas K.  CONT NAVAIR 2109,
1, N139 <douglas.k.miller at navy.mil> wrote:
> I think the question being posed here is whether or not DBus will
> work across machine boundaries in a network of Linux/Windows
> machines. Has anybody implemented that?

It might help to read up on
http://dbus.freedesktop.org/doc/dbus-specification.html

Anyway, there are really three different things that people mean, when
they refer to "D-Bus":

 1. The system message bus and its services

 2. The session message bus and its services

 3. D-Bus peer-to-peer connections

On most UNIX systems (Linux in particular), there is a system bus
running that apps can connect to. On Windows and OS X there is
typically not (to the best of my knowledge, neither Microsoft nor
Apple ship an implementation of the D-Bus protocol). On most UNIX
systems, the session message bus is started at login. On Windows and
OS X the session bus is usually started when needed (typically each
app using D-Bus is shipping its own copy of the message bus (it has
to) - so it even varies what version of the bus code that is running).

Note that D-Bus peer-to-peer over TCP/IP works just fine and is in use
in production - for example, gnome-disk-utility uses a D-Bus
peer-to-peer connection to the udisks daemon over TCP/IP over a SSH
tunnel to provide a "connect to server" feature (it also uses
mDNS/Avahi):

 http://people.freedesktop.org/~david/palimpsest-connect-to-server.png

Btw, there's no reason that the "client" (e.g. gnome-disks-utility)
couldn't run on Windows or OS X (GTK+ is cross-platform etc.) and
connect to a UDisks instance on a Linux server.

But I guess that's not answering your question. If your question is
"Is it possible to allow people to connect to the system- and/or
session-buses over TCP/IP" then the answer is a combination of "yes,
it is possible (see 'man dbus-daemon'), but most things wouldn't work
the way you'd expect them to or at all" and "it's not really what you
want". Here's why

 - Security issues - no sane distro would want to open network
   ports by default. Deployments might not care if they control
   the network. But even if the network is secure, it might not
   be wise to expose attack surface.

 - It's hard to identify peers over TCP/IP - which in turns makes it hard
   to implement authorization and authentication
   - turns out (not surprisingly) you totally need the latter for non-trivial
     system services (you don't want to allow any random desktop user
     to format any random disk)
   - On the Unix transport, this is easy and we can use things like
     PolicyKit: http://hal.freedesktop.org/docs/polkit/polkit.8.html

 - The services on those buses export objects with references to local
   objects such as filesystem paths, local sockets and sessions

In my experience, a good compromise is the palimpsest/udisks route -
use a little bit of custom code to export the guts of a service over
D-Bus over TCP/IP over a SSH tunnel. Your mileage may vary.

      David