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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
