DConf configuration system

[Dave Cridland]

On Thu Apr  7 19:15:25 2005, Avery Pennarun wrote:
> On Thu, Apr 07, 2005 at 08:00:38PM +0200, Waldo Bastian wrote:
> 
> > 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)
> 
> 
I think that's an implementation detail, surely?


> This is a pretty good idea.  It maps rather closely to the way 
> UniPermGen
> works in UniConf; you have one UniConf tree with the actual 
> settings, and
> another UniConf tree with the permissions (sort of like Unix-style
> permissions) for those settings.  Then you can stack pairs of
> value/permission trees using UniListGen.
> 
> In other words, it looks like it would be possible to implement the 
> KDE
> Kiosk feature using current UniConf permissions features.

Right - I'm pretty sure ACAP would fit this too. ACAP's ACLs are just 
metadata held on every attribute within the datastore, so you can 
apply different ACLs to pretty well everything if you want. Typically 
you just use fallbacks, like the default ACL for the dataset.

Again, it's got layering - ACAP mandates at least three levels of 
inheritance, which was deemed the minimum when it was created, 
although as far as I'm aware both full ACAP servers allow for 
essentially unlimited inheritance. Again, each layer holds ACLs.

Lock-down is pretty simple, you just remove the "iw" rights 
[Insert,Write] for the user(s) in question in their own datasets. (Or 
just remove all users' "iw" rights in those datasets, which will have 
the same effect). If you then want to give the user permission to 
change their wallpaper, you can put a different ACL on that entry's 
attributes.

So effectively, this is a working example of how storing ACL 
information in with the actual data works - no need to keep it 
seperate at all, if you don't want.

Amazingly, this wasn't too difficult to implement, as I recall. The 
problem is really getting your head around what the combination of 
ACLs and inheritance means.

Dave.

dataset == directory, sorta.
entry == key, sorta.
attribute == value, sorta.