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

Filippo Giunchedi filippo at debian.org
Wed Jan 7 21:55:56 UTC 2009


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-maintainers@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
-------------- next part --------------
<!-- 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-bluetooth-maintainers/attachments/20090107/09fb98ad/attachment-0001.pgp 


More information about the Pkg-bluetooth-maintainers mailing list