Using DBus Daemon with TCP and ANONYMOUS authorization

[Schmottlach, Glenn]

> config file isn't working for you. So a good initial approach could be
> to figure out what changed.

I think the first thing to do is to determine whether or not it's really
broken via independent verification. This is not hard. Either update a
local-session.conf file or directly edit the /etc/dbus-1/session.conf
and add the following:

  <listen>tcp:host=localhost,bind=*,port=6667,family=ipv4</listen>   
  <listen>unix:tmpdir=/tmp</listen>
  <auth>EXTERNAL</auth>
  <auth>ANONYMOUS</auth>
  <allow_anonymous/>


Run the session daemon on your host. Now use something like the Python
DBus binding on another machine and try to connect to the session bus.
Here's some sample code that might require a little tweaking to work on
different hosts. I ran this on a Windows machine.

import sys
import os.path
sys.path.append(os.path.join(sys.prefix, 'lib', 'site-packages',
'dbus'))

import dbus
import gobject
from dbus.mainloop.glib import DBusGMainLoop

class _Method:
    """Magical proxy method class."""
    def __init__(self, send, name):
        self.__send = send
        self.__name = name
    def __getattr__(self, name):
        return _Method(self.__send, "%s.%s" % (self.__name, name))
    def __call__(self, *args):
        return self.__send.get_dbus_method(self.__name)(*args)

class DBusProxy(gobject.GObject):
    
    def __init__(self, host, port, service, object, interface):
        addr = 'tcp:host=%s,port=%d' % (host, port)
        bus = dbus.bus.BusConnection(addr, DBusGMainLoop())
        obj = bus.get_object(service, object)
        self._proxy = dbus.Interface(obj, interface)

    def __getattr__(self, name):
        return _Method(self._proxy, name)

if __name__ == '__main__':
    proxy = DBusProxy('127.0.0.1', 6667, SERVICE, OBJECT, INTERFACE)
    proxy.CallWhateverMethod()


Without my hack, it throws an exception when I try to create a 'bus'
instance in the DBusProxy constructor.

Again, I don't believe this is too tough to reproduce assuming you've
had some experience with DBus. It's possible I'm missing something in
the configuration which causes it to fail but I need someone who has
used this feature before to verify my configuration. Any takers???

> I would think some particular errno from the credential-reading system
> call might be treated as "successfully read no credentials" rather
> than "failed to read credentials", would require some research into
> which one.

I'm not sure how easy this would be to differentiate between "successful
read, no credentials" and "failed to read credentials" since there is
not natural indicator of one versus the other.


> Nah, the right fix is that the code should support a missing UID.
> Missing UID will happen on Windows also for example, where we'll have
> an sid or something instead.

Okay

> If you post some kind of simple test case you might have better luck
> getting a volunteer here.

See above. I'm not sure how much easier I can make it to test. It
certainly doesn't take rocket-science to set up.

> works, it's unlikely anyone else will get to this anytime soon, unless
> they are trying to use the feature themselves. Just trying to set
> accurate expectations. But if you post questions or proposed patches I
> will try to answer them.

I have no expectations and appreciate you taking the time to answer the
questions I have posted. I'm surprised some of the embedded Linux folks
using DBus in cell phones, PDAs, etc... haven't been crying for such a
feature. It sure makes testing your services much easier when you can
develop scripts (using Python, Perl, Ruby, etc...) on your host system
to exercise your target platform where CPU/RAM may be at a premium. Oh
well, either I'll get the time for a "proper" fix or keep my hack since
it works (albeit requiring manual integration with each DBus release).