Re: GLF- Gnome Lockdown Framework

[Mark McLoughlin <mark skynet ie>]

Hi,

On Tue, 2004-03-02 at 09:57, arch enterprise hb se wrote:
> > Desktop lockdown has been discussed previously on this list (google for
> > the discussion), and some people have already added gconf keys for this
> > and started implementing it. 
> >
> 
> I'm well aware that lockdown features have been previously discussed and
> declared as somehing that is *needed* (see eg
> http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00357.html),
> but there seems to be no *framework* or *standards* settled. Concerning
> implementations, are they done with a policy tool in mind that allows for
> setting per-group, per-user or default policies/permissions?

	You have the right idea, but I think you're coming at the problem from
the wrong angle.

	Basically, what you want is for a system administrator to be able to
define a users settings based on that user's role, right?

	Here's where I think you're missing some fundamental concepts about
GConf:

  + Any setting/preference can be locked down - so why define another 
    framework on top of GConf specifically for settings which we feel
    are "lockdown" settings?

  + Any support for locking down settings based on role/user/group or 
    machine should be done using backends rather than another framework
    on top of GConf. e.g.

      - We already have hacky ways of doing this - say[1] you have two
        sets of people in an organisation and all users had the
        $SOCIAL_STATUS env variable set to either "drone" or 
        "big_bucks_manager" accordingly.

        A sysadmin could then deploy two sets of defaults/mandatory
        GConf databases and change the GConf to use the appropriate
        defaults based on the users $SOCIAL_STATUS. i.e.

        Have, the following distinct set of defaults:

           /mnt/acme.com/drone/gconf.xml.defaults
           /mnt/acme.com/drone/gconf.xml.mandatory
           /mnt/acme.com/big_bucks_manager/gconf.xml.defaults
           /mnt/acme.com/big_bucks_manager/gconf.xml.mandatory

        and setup /etc/gconf/2/path to something like:

            xml:readonly:/mnt/acme.com/$(ENV_SOCIAL_STATUS)/gconf.xml.mandatory
            xml:readonly:/etc/gconf/gconf.xml.mandatory

            xml:readwrite:$(HOME)/.gconf

            xml:readonly:/mnt/acme.com/$(ENV_SOCIAL_STATUS)/gconf.xml.mandatory
            xml:readonly:/etc/gconf/gconf.xml.defaults

        With a setup like this, you could easily do something like 
        funnel the drones through one proxy server (and not allow them
        to change it) and funnel the managers through another, more
        lightly loaded proxy server (and allow them to change) it.
        And then if someone gets promoted, you change their 
        $SOCIAL_STATUS.

      - A solution[2] that wouldn't be a hack would be a new GConf 
        backend that pulls a users default/mandatory settings from LDAP
        based on that users identity. You could then have a nice tool
        for setting up these defaults on a per-role or per-user basis.

Good Luck,
Mark.

[1] - I'm just being very hypothetical - I wish we had some docs on how
to apply ideas like this to real use cases.

[2] - I seem to recall some big company doing something like this. But
it was proprietary. Suck. I can't remember offhand who that was
though...