From: Andreas V. <li...@br...> - 2009-10-05 21:40:24
|
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 regards Andreas |
From: Randell J. <rj...@wg...> - 2009-10-06 03:08:57
|
>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 You didn't give the code used with dbus-c++ - the error implies (end the rest of what you wrote) it's NOT (just) calling or.bluez.Manager.DefaultAdapter. The error implies bluephone tried to register the name org.bluez, which your dbus-send and python tests didn't do. -- Randell Jesup, Worldgate (developers of the Ojo videophone) rj...@wg... |
From: Andreas V. <li...@br...> - 2009-10-06 19:20:20
|
Am Mon, 05 Oct 2009 23:08:36 -0400 schrieb Randell Jesup: > >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 > > You didn't give the code used with dbus-c++ - the error implies (end > the rest of what you wrote) it's NOT (just) calling > or.bluez.Manager.DefaultAdapter. The error implies bluephone tried to > register the name org.bluez, which your dbus-send and python tests > didn't do. Ah, you're right. I made a copy&paste error from my own server example. :-( If I simply omit the request_name() call then it works like expected :-) regards Andreas |
From: Andreas V. <li...@br...> - 2009-10-31 15:05:14
|
Am Fri, 30 Oct 2009 19:33:48 -0400 (EDT) schrieb John Palmieri: > > 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. I develop dbus-c++, but as I didn't start the project I don't know all technical details. Here I copied a wrong example and wondered why it doesn't work. As you see in my other post the problem is solved. :-) regards Andreas |