Conclusions and a compact list of requirements for deconf-spec
jamiemcc at blueyonder.co.uk
Mon Dec 12 14:11:52 EET 2005
Philip Van Hoof wrote:
> My current idea for the deconf-desk service is to "only" cache the type
> signatures of the keys in the service's process address space. This can
> be written (with some bitwise operations and other cool techniques) in
> extremely small bitmaps and or lists. This can even be made mmap'able on
> some platforms. There's not going to be a possible way to tell me that
> it'll have a big impact on performance or memory of that service. It
> just wont. There's simply WAY to many ways to solve this. The only
> things needed to be cached in the service (for network transparency to
> be made possible) is things like the type information.
> If the network admin overwrites the default "values", then of course
> also that is to be stored (and can also be made mmap'able since all that
> doesn't have to be humanly readable at all: this data isn't specified so
> it's an implementation detail). The whole idea of network transparency
> is overwriting (overloading) the default value, and force eliminating
> the custom user value via a central administrative location (over the
> wire) ... in a secure way (of course).
> And since also the type information is an administrative security
> consideration .. a network transparent administrable configuration
> environment is about overloading schema's. Nothing more, nothing less.
> Because .. what does a schema contain?
> - The default value
> - The type information
> - The description
The problem is for an enterprise friendly system, an admin must be able
to edit other peoples keys without having the respective schemae
installed locally on the administrator's machine (so its not just about
Ergo a system that enforces cleint side schemae only is fatally flawed.
Consider an admin using GConfEditor to enter values in a remote LDAP
server -he may or may not have the schema locally so he will need to get
from LDAP all the relevant schema data including type, validation and
descriptions (as GConfEditor would need this). The server (service)
would then have to enforce this validation to make sure erroneous values
were not entered.
If some platforms are not interested in enterprise features (and I do
respect that) then it would be better to make schemae optional in those
cases (client side schema handling buys you nothing in thoses cases
anyhow as the app will know what to expect)
Mr Jamie McCracken
More information about the xdg