DConf Database Suggestion

[Jamie McCracken]

>>> For the specific task of lockdowns, etc, I find it unlikely that 
>>> SQL's GRANT functionality will be up to the task of handling the 
>>> granularity of ACL that a configuration system requires. Wouldn't 
>>> this only be able to, in effect, control SELECT, UPDATE and INSERT 
>>> across entire tables?
>>
>>
>> Yes thats right for individual users. But my understanding is there 
>> will be multiple tables -
>>
>> 1) table for default settings
>> 2) table for specifying which keys a user can update and fixed values 
>> for ones they cant.
>> 3) a table to hold the actual key values a user is allowed to change.
>>
>> A DBA would then revoke write priveleges for a user for tables 1 and 2 
>> and grant it for table 3.
>>
>> Table 3 would also need to be prefixed/namespaced with the username so 
>> multiple user's settings can reside in the same database on the server.
> 
> 
> I personally think that here, you're getting very bogged down in the 
> implementation details of a system which doesn't exist.
> 
> Moreover, I still don't see how that allows the administrator to force a 
> particular email client on a user whilst allowing them to change their 
> desktop background.

Okay let me clarify:

Table 1 is for basically the Gconf schema (or its equivalent). This 
table might be stored in a local database (or text file) so that if the 
sql server is down you still have emergency fallback values.

Table 2 is your ACL table and its here that you will specify which 
users/groups can update which keys - IOW for your example the email 
client to use would be specified in this table and the corresponding 
key(s) would be marked non configurable for the users/groups

Table 3 is for user configurable settings like as you specified  setting 
the desktop background. All keys not locked down in table 2 would be 
settable here. This is obviously a per user table.


> 
> Finally, I think this sort of storage-level fiddling is largely similar 
> to telling UNIX admins to ignore the package manager. Yes, it's 
> possible, but it's rarely a good idea.

Well its no different for LDAP which the KDE folks would like. (I 
actually think remote admin is a core requirement for DConf and its a 
significant part of the "lets make sure DConf is better than what we 
currently have")

jamie.






> 
> Dave.
> 
>