Using DBus Daemon with TCP and ANONYMOUS authorization

Schmottlach, Glenn GSchmott at
Tue Nov 18 05:16:37 PST 2008

> Not sure, but the way I think it should work on TCP is that reading
> credentials succeeds (returns true / doesn't set error) but returns
> empty credentials. The connection should not be dropped in this case.

So, this would imply that _dbus_read_credentials_socket() is somehow
smart enough to know that it's attempting to read credential information
from a file descriptor associated with a TCP socket vs. a local socket.
I don't think this can be done because there isn't enough contextual
information passed into that function to determine the file descriptor
is from a TCP socket. Assuming the signature of this function should not
change the best place to do this check seems like it might be in
exchange_credentials() but I am not sure the DBusTransport structure
differentiates between the two types of sockets.

> Then the dbus-daemon code should be able to work with a DBusConnection
> that has no UID set.

I assumed the UID had to be set. I guess another tag could be added to
the session/system configuration file that specifies a default UID of
anonymous TCP connections.

> Setting UID of the daemon is not right.

Agreed, in the general case, this is a hack and opens a security hole.
For my application (an embedded target), however, it's acceptable since
this is only a "debug" feature that's turned off when the product is
shipped. On my target, all processes are running with root privilege (as
well as the daemon) so this is the normal situation.

> When adding <allow_anonymous/> was discussed on the list, I remember
> raising the question of whether the dbus-daemon code would in fact
> work on a DBusConnection that did not have a UID set.

I guess the motto is "use it until something doesn't appear to work any
longer". Perhaps the person who applied the patch might have some
insight on this.

> So it's possible the patch just doesn't work, or that TCP just doesn't
> work. Just a matter of debugging it. (And perhaps adding a unit test.)

Well, I've certainly looked into it enough to say that it doesn't
*appear* to work correctly as implemented. Since I'm a bit of a DBus
novice, I'd appreciate anyone who could do an independent verification
(which doesn't appear to be hard to do). My patched approach won't pass
muster as a final fix if indeed this is a bug. It gets me past my
immediate hurdle but I suspect someone more familiar with the code might
be able to suggest an alternative (and more correct) approach. Are there
any takers to "officially" investigate this issue and roll in a patch?
Should I log a bug in Bugzilla?

More information about the dbus mailing list