Created attachment 20960 [details] [review]
Right now HAL has a lot of manual interface rules in the allow; if we're really using PolicyKit now it seems to me we could replace all of them with the simple:
But I've chosen to attach a patch which is conservate and just explicitly enables introspection.
Created attachment 21023 [details] [review]
Propose replacing the existing .conf.in with this upstream, moving the other one to hal-nopolicykit.conf.in. (Possibly add a configure option?)
Ping on this bug - I want to do a new dbus release with logging, and NetworkManager talking to HAL constantly warns about the KillSwitch method.
I think we need to discuss this upstream. I would prefer a much less invasive patch as HAL is in effective feature freeze.
(Aren't we discussing this upstream now?) Ok, I'll see about putting together a targeted patch.
Created attachment 21326 [details] [review]
allow introspection and Device.KillSwitch access
This one just allows introspection and Device.KillSwitch access. There may be others.
For reference, this is Debian bug <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510639>; I put some notes and proposed patches there while trying to fix it in the (older?) version used in Debian 5.0.
A perhaps-simpler way to fix NetworkManager's use of hal would be to allow root to access all of hal's functionality, which I've proposed as a patch to the Debian package. Since root is allowed to replace or impersonate hal, being able to access hal seems fairly uncontroversial.
hal also has the bug tracked by <http://bugs.freedesktop.org/show_bug.cgi?id=18961> (send_interface without send_destination) which I've proposed as a patch; it won't apply upstream without minor modification since I applied it after the Debian-specific group-based access control patch, but the changes are hopefully obvious.
According to some quick testing, gnome-power-manager (at least at the version in Debian 5.0) also wants to access the CPUFreq interface, so that should probably be allowed for users who are at_console (or some other suitable access control - in Debian it's the powerdev group, but that's Debian-specific anyway). I also suggested allowing DockStation and WakeOnLan, which seemed in-scope for the Debian powerdev group.
Which other interfaces have I missed, that are "fairly safe" for users with physical access?
This also seems to be https://bugzilla.redhat.com/show_bug.cgi?id=476043
It should be fixed now in git master.