[Pkg-utopia-maintainers] [Pkg-bluetooth-maintainers] Bug#510644: Debian Bug#510644: bluetooth.conf needs alterations for new D-Bus

Filippo Giunchedi filippo at debian.org
Mon Jan 5 22:32:50 UTC 2009


On Mon, Jan 05, 2009 at 08:32:58PM +0000, Simon McVittie wrote:
> >   <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?

Unfortunately they don't a well known service name nor object path, agents are
user-registered

> 
> (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?)

That is <allow send_interface="org.bluez.Agent"/> ?

I think so, yes. (note that upstream 4.x uses org.bluez.Agent while 3.x (which
is debian) uses org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent but they
basically the same)

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

I just retried and indeed it seems to work without, thanks for spotting this.

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

Mh, no it wouldn't be safe indeed.

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

Okay, given that using AF_BLUETOOTH sockets requires CAP_NET_ADMIN for some
ioctls I'd go for netdev group, makes sense?

thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

Either this man is dead or my watch has stopped.
-- Groucho Marx



More information about the Pkg-utopia-maintainers mailing list