An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Thu, 2005-04-07 at 16:02 -0400, Avery Pennarun wrote:

> In a config system, the problem comes down to this: nobody wants an
> "asynchronous get" command in their config system, because it turns simple
> things like "what colour should I make this widget" into a multi-line
> callback/state machine nightmare.  But if you're querying the network, you
> have to be asynchronous, because it could take an undefined amount of time
> for the answer to come back, and you can't afford to freeze your app in the
> meantime.  Threads don't help, because *all* the threads want to know things
> about the configuration.

No no no no :). You misunderstood the text. Every desktop will run AND
cache it's own configuration system. Only for pushing new configuration
data will network transparency be used. Some keys, therefor, aren't
writable. It basically means that the original location HAS to be an
authorized source (like another daemon, or like an ACAP-server).

So the backend will always be local on the system that needs the
configuration. Some keys will be protected. 

I KNOW you can't make this uncrackable if that "daemon" (which is called
the conductor on the wiki) runs as the same user who is using that
desktop.

Running the process privileged (user root) can solve this. However. In
my humble opinion is this overkill (and not very portable). And it will
have a security impact (some bugs are suddenly much more serious).

So it's more to "protect" the user from setting certain settings.
Setting which would be originated from an authorized source (like a
configuration server or however you want to call this).


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org