Re: lock down features

[Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>]

If I understood you correctly, this should be pretty useful for large
scale deployments. I can think of situations where administrators who
look after a lot of desktops would want to restrict at an atomic level
what individual desktop users are allowed to change. 

Is this is what you're aiming at ? In this case, gconfd should probably
read from a global DB at startup (which, of course, might be another
global gconf XML file located at, say, $prefix/share/gconf/). The
administrative user can manipulate the global gconf DB to apply
restrictions, maybe using gconf-editor itself. For the global gconf db,
the key might be the key name to be locked and the value would be a
gboolean indicating whether the key is locked or not. If a key does not
exist, it would be assumed to be unlocked by default. The same principle
can be applied for directories. If a directory name exists as key with
lock status as TRUE, then no key of the directory is modifyable. 

When a user asks for a key to be modified, the user-specific gconf
daemon should check against the global rules DB read at startup whether
the user is allowed to modify the key or not. Also, it should be simple
to patch gconf-editor, configuration dialogs, etc. to gray out those
choices which the user is not allowed to change. For this, we'll
probably need to extend the GConf API with something like
gconf_is_key_locked(const char *key). This would involve a few string
comparison checks but shouldn't slow things down too much. 

Another thing to think about is that once we have proper shared DB
backends for GConf, we can probably use the DB permissions itself for
atomic key locking. 

Hope I'm taking/making sense here. 

Rgds, 
Biswa. 

> Hi,
> 
> We should consider a feature allowing people to lock down various
> parts of the desktop.
> 
> Part of this is simply honoring the writability or nonwritability of
> gconf keys, which some things don't do properly right now. We should
> fix those things.
> 
> There are two reasons that isn't quite enough:
> 
>  - gconf doesn't currently let you mark a directory not writable,
>    so e.g. you can't lock down all possible entries in /apps/metacity
>    (should be fixed really)
> 
>  - sometimes what we want to lock won't correspond to a preference
> 
> 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.
> 
> If can_edit_menus is false, you can't edit menus in nautilus or via
> other means.
> 
> You get the idea.
> 
> What do people think? How should we implement this?
> 
> Havoc
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
>