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