Re: New modules in 2.14

[David Zeuthen <david fubar dk>]

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