dbus_bus_request_name with bluez

John Palmieri johnp at redhat.com
Fri Oct 30 16:33:48 PDT 2009


----- "Andreas Volz" <lists at brachttal.net> wrote:

> Hello,
> 
> I'm developing the dbus-c++, but I think my problem is dbus specific.
> So I ask here.
> 
> This is what I do on the terminal:
> 
> > dbus-send --system --type=method_call --print-reply --dest=org.bluez
> / org.bluez.Manager.DefaultAdapter
> 
> method return sender=:1.43 -> dest=:1.81 reply_serial=2
>    object path "/org/bluez/11832/hci0"
> 
> This works well. So I tried the python code:
> 
> bus = dbus.SystemBus()
> 
> bluez = dbus.Interface(bus.get_object("org.bluez", "/"),
> 						"org.bluez.Manager")
> 
> print "DefaultAdapter: " + bluez.DefaultAdapter ()
> 
> This prints:
> 
> DefaultAdapter: /org/bluez/11832/hci0
> 
> Also working, so I tested it with dbus-c++ and I get this error:
> 
> > ./bluephone 
> terminate called after throwing an instance of 'DBus::Error'
>   what():  Connection ":1.83" is not allowed to own the service
> "org.bluez" due 
>   to security policies in the configuration file
> Aborted
> 
> So I debugged into the library and see this C code:
> 
> void Connection::request_name(const char *name, int flags)
> {
> 	InternalError e;
> 
> 	debug_log("%s: registering bus name %s", unique_name(), name);
> 
> 	int ret = dbus_bus_request_name(_pvt->conn, name, flags, e);
> 
>         if (ret == -1)
>         {
> 	       if (e) throw Error(e);
>         }
> 
> 	if (name)
> 	{
> 		_pvt->names.push_back(name);
> 		std::string match = "destination='" + _pvt->names.back() + "'";
> 		add_match(match.c_str());
> 	}
> }
> 
> Debugger says:
> 
> flags = 0
> name = "org.bluez"
> ret = -1
> 
> So it throws the Error in this case. If I comment out the Exception
> throw
> than my example works without problems. This is really strange and
> gets me 
> to some questions:
> 
> * Did I a mistake?
> 
> * Why is the dbus-send working?
> 
> * Why is the Python example working
> 
> * Why does DBus simply give my application access to the liked
> service
>   only by ignoring the error handling? Isn't this a little insecure?
> 
> BTW: I just found out if I start my application as root it also works
> with enabled exception handling. Have I found a security hole (at
> least
> in dbus-python and dbus-send)?
> 
> bluez-4.12-0ubuntu5

Wait, I don't understand.  Are you developing dbus-c++ or are you just using dbus-c++?  Why is request_name being called? Requesting a name on a connection means you want to register that connection under the given common name.  Since bluez already has that name then you generate a D-Bus error.  None of the code above, either dbus-send or the python code ever calls request_name on the bluez common name so you wouldn't get that error. dbus-c++ for some reason is calling request_name when it shouldn't or you are using the C++ code wrong.  Perhaps there is two different connections - one if you want to provide a service and another for clients wishing to connect to a service?  I've never used them so I am not completely sure.

--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.


More information about the dbus mailing list