D-BUS for Network RPC

[Havoc Pennington]

On Wed, 2005-01-19 at 22:29 +0000, Daniel P. Berrange wrote:
> On Wed, Jan 19, 2005 at 11:53:12AM -0500, Havoc Pennington wrote:
> > On Wed, 2005-01-19 at 10:42 -0500, Stephen J. Scheck wrote:
> > > - How does the design and architecture of D-BUS make it optimized for 
> > >   local use, and thus would make it unsuitable/inefficient for network 
> > >   RPC? Is there any reason why it wouldn't make a good candidate for
> > >   simple and light-weight network RPC applications?
> > 
> > It probably works OK, it just hasn't been designed or thought about in
> > that context.
> 
> While it may not be specifically designed with networked use in mind, one 
> can easily envisage scenarios where it'll be important for DBus to operate
> well across networked machines - not arbitrarily connected across the 
> Internet - but certainly in a LAN environment & probably corporate WANs
> too.

I should amend my statement; D-BUS does intentionally include the usual
"X protocol over TCP" case of running a remote app that connects to your
session bus daemon. This case is what the "magic cookie in homedir" auth
mechanism is intended to handle.

What hasn't been thought about is a context aside from the session
daemon, where maybe you don't have a user or a homedir in mind in
advance. I don't know how the auth works in that case. Also, there's no
encryption for now so Internet usage is kind of out.

It's been suggested that the encryption just use ssh to set up a tunnel,
in order to avoid packing a bunch of ssl bloat into libdbus, and I
suppose that may make sense for the "connect a remote app to session
bus" case. I haven't looked into any of the details though and ssl is
more what you want for providing a generic TCP service other than the
session bus.

Havoc