|Summary:||explicitly allow Introspection and other disallowed interfaces|
|Product:||hal||Reporter:||Colin Walters <walters>|
|Component:||hald||Assignee:||David Zeuthen (not reading bugmail) <zeuthen>|
|Status:||RESOLVED FIXED||QA Contact:|
|Priority:||medium||CC:||bugzilla, danny.kukawka, kai.kasurinen, richard, walters|
|i915 platform:||i915 features:|
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.