Issues while using DBUS over TCP

[Havoc Pennington]

Hi,

See also
http://lists.freedesktop.org/archives/dbus/2008-July/010176.html

The two use-cases that current TCP support has been written for are:

* to share the session bus when a user is logged into two machines
sharing a home directory via a networked filesystem
* to write a custom DBusServer (NOT a dbus-daemon) that accepts
anonymous connections

Nobody has coded support for "have a custom dbus-daemon exported over tcp"

As mentioned at
http://www.freedesktop.org/wiki/Software/DBusRemote
(should link to your tcp doc from there probably) there's also no
transport security (eg TLS) or firewall-hopping.

On Wed, Aug 6, 2008 at 1:34 PM, Schmottlach, Glenn
<GSchmott at harmanbecker.com> wrote:
> Actually, I am
> quite surprised DBUS over TCP has received such little attention and
> support. It seems like this might've been a feature that would've been
> added years ago

It's pretty simple really; nobody who wants to use dbus in this way
has ever done the work. The people doing the two cases mentioned above
(shared session bus with networked homedir, and custom DBusServer
taking anonymous connections) did the work and merged the patches into
mainline. But to the extent people have used dbus over tcp in other
ways, they haven't figured out all the issues, written them up, and
submitted patches.

I would also footnote, we really don't want to compromise the central
use-cases of dbus for alternative uses that we don't necessarily
understand ... so simple additions sure, but adding big new hunks of
code or features solely to repurpose or genericize dbus, would give me
pause. There are hundreds of IPC systems in the world, and dbus is not
supposed to be a hammer for all nails.

> Who added the original TCP support? It seems like the support is
> *almost* there.

I think I added it for the above-mentioned two cases.

> Is there way to currently do this WITHOUT requiring shared
> directories etc...?

Nope, the only auth mechanisms are reading credentials off unix domain
socket (useless for tcp) and proving you can see private cookie files
in the homedir of the user you are auth'ing as (useless without shared
homedir). And ANONYMOUS of course, but that doesn't prove any
identity.

I don't honestly know how you'd do auth in a case like yours, which is
one reason there isn't any support for it. It almost seems like you
need some sort of custom thing.

> Does it work with the Python client bindings? What
> is the use-case of the current TCP support? It appears almost useless
> without enabling ANONYMOUS access and authentication at the daemon. This
> leads me to believe I may be misunderstanding how this feature should be
> used.

You may be assuming you have to use dbus-daemon to use libdbus and the
dbus protocol. The limitations around ANONYMOUS have to do with the
daemon, not with the protocol. The daemon is only one specific app
that speaks dbus protocol.

Havoc