Re: lock down features

[Jonathan Blandford <jrb redhat com>]

Havoc Pennington <hp redhat com> writes:

> Hi,
> 
> We should consider a feature allowing people to lock down various
> parts of the desktop.

Agreed.

> Anyhow, I think we may want some settings like this:
> 
>  /desktop/gnome/capabilities/can_run_commands
>  /desktop/gnome/capabilities/can_edit_menus
>  /apps/panel/capabilities/can_change_applets
> 
> So e.g. if can_run_commands is FALSE, you can't open the Run Command
> dialog or do other things that allow you to start up a command.  Apps
> would optionally be able to honor this setting. This isn't related to
> a preference.

This will be really tricky to audit...

> What do people think? How should we implement this?

The control-center needs to handle locked down keys better.  One problem
I have in implementing this is that I'm not really sure how to let the
user know why certain graphical elements are insensitive.

This will definitely be a desktop-wide push.  I think the right thing to
start with is to determine which bullet points we want (and which are
genuinely useful!)

Some random thoughts:

 * Lock down various configuration options

 * Lock down the set of applications available

 * Provide gconf backend that can scale beyond individual users (ie:
   groups)

 * Documentation/admin tool

 * 'Reset to default' feature for keys.  I almost feel that, in
   conjunction with the lock down feature, we need a better way of
   associating sets of keys.  For example, a user just installed and
   switched to the BSOD theme, and now can't switch out.  The admin
   doesn't want reset all their keys -- just the ones that deal with a
   key.  Perhaps this should be more part

 * propagation to other parts of the desktop.  For example, we need
   mozilla to be able to lock bookmarks and cookies.  We might want
   office apps to all default to save in a standard location.

Feel free to add other ideas.
-Jonathan