Bug 18985

Summary: explicitly allow Introspection and other disallowed interfaces
Product: hal Reporter: Colin Walters <walters>
Component: haldAssignee: David Zeuthen (not reading bugmail) <zeuthen>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: bugzilla, danny.kukawka, kai.kasurinen, richard, walters
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: allow introspection
proposed hal.conf.in
allow introspection and Device.KillSwitch access

Description Colin Walters 2008-12-09 12:12:30 UTC
Created attachment 20960 [details] [review]
allow introspection

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:

<allow send_destination="org.freedesktop.Hal"/>

But I've chosen to attach a patch which is conservate and just explicitly enables introspection.
Comment 1 Colin Walters 2008-12-10 12:35:52 UTC
Created attachment 21023 [details] [review]
proposed hal.conf.in

Propose replacing the existing .conf.in with this upstream, moving the other one to hal-nopolicykit.conf.in.  (Possibly add a configure option?)
Comment 2 Colin Walters 2008-12-18 13:51:00 UTC
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.
Comment 3 Richard Hughes 2008-12-19 02:04:50 UTC
I think we need to discuss this upstream. I would prefer a much less invasive patch as HAL is in effective feature freeze.
Comment 4 Colin Walters 2008-12-19 08:53:02 UTC
(Aren't we discussing this upstream now?)  Ok, I'll see about putting together a targeted patch.
Comment 5 Colin Walters 2008-12-19 11:27:29 UTC
Created attachment 21326 [details] [review]
allow introspection and Device.KillSwitch access

This one just allows introspection and Device.KillSwitch access.  There may be others.
Comment 6 Simon McVittie 2009-01-05 07:39:06 UTC
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?
Comment 7 Simon McVittie 2009-01-05 07:50:37 UTC
This also seems to be https://bugzilla.redhat.com/show_bug.cgi?id=476043
Comment 8 Danny Kukawka 2009-01-29 06:37:18 UTC
It should be fixed now in git master. 

Check: http://cgit.freedesktop.org/hal/tree/hal.conf.in