DConf configuration system

[Waldo Bastian]

On Thursday 07 April 2005 15:35, Joerg Barfurth wrote:
> I don't think you can attach access priviledges to keys or folders in
> the namespace directly. In a stacked scenario they apply to instances of
> a key in the various layers (e.g. I may be allowed to change my personal
> preference, but not the group or site default). IME it is even
> sufficient to apply access priviledges to entire layers. Any such access
> control also has to correspond with other ways to modify the underlying
> data. This fits the access control by layer model well. Protecting a key
> is not much use, if the user can change it by manually editing a config
> file. OTOH you don't want to store user preferences in a file that only
> root can modify.

There are two different kind of restrictions here:
(1) Can user X change the preference setting for a setting in layer Y (Who is 
allowed to change the default?)
(2) Are settings in layer Y considered at all for user X? (Lock down: Is user 
X allowed to have a setting other than the default?)

Typically when the user makes a change, that change is stored in the first 
layer (and e.g. stored somewhere under $HOME), by ignoring certain keys in 
this layer (2) you effectively make those keys read-only, especially since 
the user is typically only allowed to change preferences in the first layer 
(1).

KConfig, as part of KDE KIOSK, allows you to mark individual keys (or even 
whole groups) immutable and KConfig will ignore any value for that key stored 
in the first layer, so the application will always use the (group or site) 
default for such keys. 

The question though is what is the most effective way to manage this. Do you 
want to store information about whether a default can be overridden by the 
user's personal setting together with the default setting itself (as KConfig 
does), or do you want to have a separate file that specifies which keys can 
be overridden, and which ones can not? The answer to that question depends on 
how you manage your settings as a whole I think. I like the KConfig approach 
because it makes it easy to create self-contained profiles that can be 
assigned to users. But maybe both should be possible if you want to 
micro-manage things (e.g. give a specific user the possibility to change his 
wallpaper while the default policy is to have locked down wallpaper settings)

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050407/e4b72461/attachment.pgp