DConf Database Suggestion

[Jamie McCracken]

Dave Cridland wrote:

>> Okay let me clarify:
>>
>>
> Yes, you've clarified, but not in a way that clarifies how SQL's 
> GRANT/REVOKE actually help here. It's quite possible I'm just being 
> unbelievably stupid, but I'd greatly appreciate knowing how.

Simply you need to write protect ACL table from unauthorised users - 
that is the key to lockdown.


> No, indeed, it's no different from LDAP, or any local-only system. That 
> doesn't change my position one iota. Adminisrators shouldn't be 
> tinkering directly with the configuration store in anything like normal 
> usage, they need a toolset to do the work.

Which DConf should provide. Its API needs to be suitable for the needs 
of remote admin (IE it must provide some form of administratable ACL, 
user/grouping, remote control etc). I'm not saying everything needs to 
be handled by a DBA -  we should have means for non-DBAs. However the 
ease with which a DBA could manipulate everything without resorting to 
such toolsets is obviously a bonus for them.

> 
> Personally, I'd like this toolset to operate through the standard API 
> that everything else uses, so there's no possibility of using the "wrong 
> tool". The way I'd suggest doing this would be to ensure that the data 
> model exposed by the API had these two properties:
> 
> 1) ACL and stacking data was exposed in the same way as other data. 
> Perhaps it's a special-named key with a funky value, or another bit of 
> metadata on the key.
> 
> 2) Consumers of the D-BUS interface always request a "full path" to 
> their configuration data, which includes the username if applicable. 
> (Possibly using a shortcut of ~ somewhere.) This isn't a particularly 
> onerous requirement, and would be handled by the toolkit specific 
> configuration API anyway, most likely.
> 
> Then you have a configuration "master tree" which has usernames and 
> scopes at the top of it, something like:
> 
> /site/  - Defaults for everyone.
> /group/foo/ - Defaults for group foo. foo needn't be a UNIX group.
> /user/bar/ - Configuration data for user bar.

This is equivalent to my three tables :)

> 
> All of them in the same "format", so that stacking works neatly.
> 
> Stacking information could be held in, say, /~/stacking, so 
> /user/bar/stacking has a value of /group/foo/, and /group/foo/stacking 
> has a value of /site/. The net result is that anyone who has permission 
> can alter their own - or other people's - stacking on the fly. Most 
> people won't have that permission, but administrators will.
> 
> This idea is lifted almost directly out of ACAP, just simplified rather 
> heavily. This is what I meant in another thread about it being a good 
> idea not to dismiss ACAP out of hand - there's a lot of good ideas in 
> ACAP, whether anyone uses them or not. (ACAP is used, by the way, just 
> not very heavily. If we're running a popularity contest though, let's 
> all install Windows.)

Sorry Im not familiar with ACAP but coincidently it seems the same as 
what I proposed using tables so I guess we are both on the right track :)

jamie.

> 
> Dave.
> 
>