Recent fix of the DBUS default policy for system bus seems to uncover a bug in PolicyKit default policy. That policy only polkituser to own org.freedesktop.PolicyKit, but does not specify any allow rules. If any user is expected to be able to send requests to polkitd over DBUS, policy should probably get something like: <policy context="default"> <allow send_destination="org.freedesktop.PolicyKit"/> </policy> This problem was observed at least with system-config-services.
Hmm, I'm not seeing this with my F10 box with the latest D-Bus packages, see below. Can you try dbus-send on your system? I am however seeing issues with the PackageKit packages since I'm getting "failed to get a TID: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.PackageKit.Transaction" member "SetLocale" error name "(unset)" destination "org.freedesktop.PackageKit") (0)" which shows I'm using the right D-Bus packages... Weird, I wonder why PolicyKit works though... $ dbus-send --print-reply --system --dest=org.freedesktop.PolicyKit / org.freedesktop.PolicyKit.IsProcessAuthorized string:org.freedesktop.policykit.grant uint32:4390 boolean:false method return sender=:1.111 -> dest=:1.126 reply_serial=2 string "auth_admin_keep_always" $ rpm -q dbus dbus-1.2.6-1.fc10.x86_64 $ grep -10 "bugs.freedesktop" /etc/dbus-1/system.conf even if they aren't in here --> <allow send_destination="org.freedesktop.DBus"/> <allow receive_sender="org.freedesktop.DBus"/> <!-- allow sending valid replies --> <allow send_requested_reply="true" send_type="method_return"/> <allow send_requested_reply="true" send_type="error"/> <!-- allow receiving valid replies --> <allow receive_requested_reply="true"/> <!-- Note: the rule above also allows receiving of all non-reply messages that are not denied later. See: https://bugs.freedesktop.org/show_bug.cgi?id=18229 Potentially this will be replaced in the future by the following two rules: <allow receive_requested_reply="true" receive_type="method_return"/> <allow receive_requested_reply="true" receive_type="error"/> --> <!-- disallow changing the activation environment of system services --> <deny send_destination="org.freedesktop.DBus" send_interface="org.freedesktop.DBus" send_member="UpdateActivationEnvironment"/> </policy> $ cat /etc/dbus-1/system.d/org.freedesktop.PolicyKit.conf <?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- --> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig> <!-- Only polkituser can own the service --> <policy user="polkituser"> <allow own="org.freedesktop.PolicyKit"/> </policy> </busconfig>
also, to test, suggest to use $$ to ask whether the shell you're using is authorized; e.g. $ dbus-send --print-reply --system --dest=org.freedesktop.PolicyKit / org.freedesktop.PolicyKit.IsProcessAuthorized string:org.freedesktop.policykit.grant uint32:$$ boolean:false should work
dbus-send gives me: # dbus-send --print-reply --system --dest=org.freedesktop.PolicyKit / org.freedesktop.PolicyKit.IsProcessAuthorized string:org.freedesktop.policykit.grant uint32:$$ boolean:false Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 I get following from s-c-services: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.PolicyKit" member "IsSystemBusNameAuthorized" error name "(unset)" destination ":1.125")
I forgot: # rpm -q dbus PolicyKit dbus-1.2.6-1.fc10.i386 PolicyKit-0.9-3.fc10.i386
Apparently you don't have Bluez installed! Colin pointed out how broken bluetooth.conf is; it opens up holes for the object path "/" for *all* services. Anyway, I can reproduce the bug now.
(In reply to comment #5) > Apparently you don't have Bluez installed! Colin pointed out how broken > bluetooth.conf is; it opens up holes for the object path "/" for *all* > services. > > Anyway, I can reproduce the bug now. > Confirming that the fix proposed in comment 0 works; am committing that one.
Created attachment 20901 [details] [review] tested patched This patch fixes the problem.
For what it's worth, this is <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510646>. I've proposed the same patch for inclusion in Debian 5.0.
This bug report is for the old version of PolicyKit. Closing as all of the code has been rewritten. Please reopen if the bug report applies to the latest version of PolicyKit. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.