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
signature.asc
Description: Digital signature
