On Wed, Jan 07, 2009 at 07:17:35PM +0000, Simon McVittie wrote: > On Mon, 05 Jan 2009 at 23:32:50 +0100, Filippo Giunchedi wrote: > > On Mon, Jan 05, 2009 at 08:32:58PM +0000, Simon McVittie wrote: > > > > <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 > > Never mind. We have a lot of these rules in the archive anyway > (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-utopia-maintain...@lists.alioth.debian.org&tag=fdo-18961) > and as far as I can tell it's not a release-critical bug, particularly > as an <allow> rule... so leave it like that unless D-Bus upstream can > explain something better. > > > > 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? > > netdev sounds the most appropriate, yes. avahi-daemon has some suitable > postinst snippets to create the group if necessary, before telling D-Bus > to reload:
okay, thanks, I'll put a note in NEWS.Debian too [...] > Apparently at_console works (or at least, can be made to work) if you have > ConsoleKit installed, so you should have two <policy> sections, one for > at_console and one for netdev, containing the same <allow> rules. > > Please go ahead with the unstable upload, but also attach the resulting > bluetooth.conf to this bug so I can review it. attached, note that I used AuthorizationAgent and PasskeyAgent interfaces because that's what bluez 3.x uses while 4.x has Agent interface filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: How do you feel about women's rights? I like either side of them. -- Groucho Marx
<!-- This configuration file specifies the required security policies
for Bluetooth core daemon to work. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
<busconfig>
<!-- ../system.conf have denied everything, so we just punch some holes -->
<policy user="root">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.PasskeyAgent"/>
<allow send_interface="org.bluez.AuthorizationAgent"/>
</policy>
<policy at_console="true">
<allow send_destination="org.bluez"/>
</policy>
<policy group="netdev">
<allow send_destination="org.bluez"/>
</policy>
</busconfig>
signature.asc
Description: Digital signature
