dbus_bus_request_name with bluez

[Andreas Volz]

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
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[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.

--
Randell Jesup, Worldgate (developers of the Ojo videophone)
rjesup@...
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Andreas Volz]

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
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[John Palmieri-2]

----- "Andreas Volz" <lists@...> 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.
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Andreas Volz]

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
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus