Using DBus Daemon with TCP and ANONYMOUS authorization

[Schmottlach, Glenn]

This summer I was able to connect to my (slightly) modified DBus daemon
over a TCP connection using the following options in my session
configuration file:

 

  <listen>tcp:host=localhost,bind=*,port=6667,family=ipv4</listen>   

  <listen>unix:tmpdir=/tmp</listen>

  <auth>EXTERNAL</auth>

<auth>ANONYMOUS</auth>

 

The small modification to the DBus daemon was an additional call to 

 

dbus_connection_set_allow_anonymous (new_connection, TRUE);

 

in the bus.c new_connection_callback() function.

 

Recently I cloned the development head when I saw that Bug 15393
<http://bugs.freedesktop.org/show_bug.cgi?id=15393>  had been applied
that allows for anonymous authorization with the new <allow_anonymous/>
tag added to the system/session configuration options.

 

I rebuilt my DBus library and daemon and attempted to connect to it
using a Python DBus client on my PC (the daemon is running on a target
platform). Fortunately, I have a debugger on the DBus daemon and I can
see it detect the new connection (via TCP), set the connection so that
it allows anonymous users, but unfortunately, it still attempts to do
local authorization via SCM_CREDS because it ends up in
do_authentication(). I've verified in the debugger that ANONYMOUS is
added as a valid authorization mechanism.

 

Can anyone suggest why I'm seeing this behavior? I thought the ANONYMOUS
option would cause the daemon to forgo authorization via SCM_CREDS. Does
the daemon always try to do SCM_CREDS authorization even for non-local
(domain) sockets? Since I have this in a debugger, I'm able to set
breakpoints pretty much anywhere so I'm open to investigating this in
more detail. I suspect, however, that I must not fully understand the
expected behavior.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20081117/12597c88/attachment.htm