On Tue, 2006-01-17 at 22:37 -0500, Ryan Lortie wrote: > This would make the system more secure as a normal user process > wouldn't be given the ability to 'suspend now' as g-p-m (and > any system which makes policy decisions at user privilege) currently > requires we provide it with. This (and other privileges that g-p-m > need to be provided with) have serious security implications.
g-p-m runs completely unprivileged; what you are worried about are the methods on HAL? You know, sane distros lock this down to only allowing console user or certain group membership. Paranoid distros use things like SELinux to only allow the /usr/bin/gnome-power-manager process to invoke the Suspend() method on HAL. (please also specify concrete attack vectors) > Having a system daemon would also mean that the policy system runs > when the user is not logged in without resorting to hacks like gdm > invoking a private copy of g-p-m. Strong disagreement, see http://blog.fubar.dk/?p=63 for some ramblings why this is exactly what one wants to do. Yes, you need to answer how the system daemon is configured when no user is logged in (don't tell me some UNIX-y scheme with a file in /etc please). > 2. More platform-neutral approach. > The technologies on which g-p-m is based have seen wide acceptance > from other desktops. We should try and create a power management > system that has the same acceptance. g-p-m is very Gnome-centric. > With a faceless system daemon doing all the real hard work we could > have multiple configuration front-ends (Gnome, Qt, etc). What is the point here? Most distributions nowadays either support only GNOME or KDE; sure, they ship the other, but focus on just one of them. Personally I think that is fine.. We'll get kick-ass GNOME distros and kick-ass KDE distros. Also.. do you really think the GNOME and KDE people can agree on a settings format for said system daemon? I think it would be a mistake. Also, from a more pragmatic point of view... Is it worth splitting e.g. g-p-m into two daemons simply to feed settings from gconf from one to the other? I think the answer to this question is no. The answer is that the approach that I outlined (which you call a hack; offends me a bit actually) allows us to 1) leverage and unlock the full power of gconf; e.g. g-p-m when running in the "no user logged in" case reads from gconf, this might stem from LDAP some day 2) It gives us an easy way to say "set these settings as system default" 3) Simplified code, e.g. keep everything in a single process just like with g-p-m today 4) Not having to fight about feature parity of the system daemon with projects that have another approach to what is configurable. Hope this helps. David _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
