Debian Bug#510644: bluetooth.conf needs alterations for new D-Bus

Simon McVittie simon.mcvittie at collabora.co.uk
Mon Jan 5 12:32:58 PST 2009


Cross-posting to D-Bus upstream and pkg-utopia Debian maintainers in an
attempt to get some clarification. We should take this to BlueZ upstream
too, once we've worked out what it is we should be recommending...

On Mon, 05 Jan 2009 at 20:32:09 +0100, Filippo Giunchedi wrote:
> It seems like upstream config was missing the reply part, I got this:
> 
>   <policy user="root">
>     <allow own="org.bluez"/>
>     <allow send_destination="org.bluez"/>

Looks fine so far...

>     <allow send_interface="org.bluez.Agent"/>

That will work but is not ideal; D-Bus upstream opinion seems to be that
a bare "send_interface" without a corresponding send_destination is
almost always an error (because it matches the corresponding interface on
completely unrelated processes). Do Agent implementations have a well-known
service name you can use?

Failing that, maybe you could at least match on object path as well as
on interface?

(Sorry, I didn't spot that upstream had done this. This is
<http://bugs.freedesktop.org/show_bug.cgi?id=18961>.
<deny> with only a send_interface is certainly harmful; <allow> like
this might be OK?)

>   <policy at_console="true">
>     <allow receive_sender="org.bluez"/>
>   </policy>

I think this is meant to be unnecessary in dbus 1.2.8 (and 1.2.1-5 in
Debian, which has the patches backported).

>   <policy context="default">
>     <allow send_destination="org.bluez"/>
>   </policy>

Is it safe for every local user to be able to call methods on the org.bluez
service? If not, this needs fixing. To match the behaviour of the lenny
bluetooth.conf it should be in <policy at_console="true">, but I don't
think that ever actually worked on Debian systems unless you have
libpam-foreground or ConsoleKit (and possibly not even then).

Debian packages usually have a dual at_console/group-based policy for device
accesses like this (e.g. members of powerdev and netdev can use various
interfaces on hal even if they are not at_console), by duplicating the
permissions of the at_console <policy> into a separate group policy. See
NetworkManager's configuration in Debian, for instance.

> and seems to work, will upload to unstable shortly.

OK, but please don't request an unblock from the release team until we've had
some feedback from D-Bus upstream; the services whose rules don't work
seem to be the complicated ones :-(

Thanks,
    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090105/ac3df192/attachment.pgp 


More information about the dbus mailing list