authentification for dbus tcp transport

[msg at altern.org]

Hi,

Excuse me for my question, I haven't found extensive documentation about
authentification when using the Tcp transport.
I dbus-launch-ed a bus with a configuration based on session.conf and with
theses modifications:
<listen>tcp:host=localhost,port=1234</listen>
<auth>ANONYMOUS</auth>

Then I can't connect even from the user who launched the bus? I get a
NoReply error which appears instantly.

Same with:
<auth>DBUS_COOKIE_SHA1</auth>
<auth>EXTERNAL</auth>
Without any <auth>, it works with the user who launched the bus, does it
mean that another authentification mecanism is used in this case? Or that
in the former cases my configuration is not properly set?

Thanks a lot!
Emmanuel E.

    busConnection = dbus.bus.BusConnection.__new__(dbus.bus.BusConnection,
busAddress)
  File "/var/lib/python-support/python2.4/dbus/bus.py", line 121, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not
receive a reply. Possible causes include: the remote application did not
send a reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.


> Think about the authentication - how could it magically work across
> multiple computers without you doing anything?
>
> You have to either add ANONYMOUS as an auth mechanism (effectively
> disables authentication), or have a working auth mechanism in place.
>
> The only two auth mechanisms in the current dbus code are
> DBUS_COOKIE_SHA1 and EXTERNAL. EXTERNAL asks the kernel for the uid on
> the other end, so it can't and doesn't work over TCP. DBUS_COOKIE_SHA1
> proves the identity of a user by having them provide a secret cookie
> found in their home directory. This can only work if both ends of the
> connection use the same homedir (either same machine, or NFS
> homedirs).
>
> If you don't have a shared homedir, aren't on the same machine, and
> don't want to enable anonymous access, then you have to implement
> something else. For example Kerberos, or whatever makes sense in your
> environment. We are happy to take patches to add new auth mechanisms.
>
> Havoc
>