To Home page

Configuration Data in a Safe Operating System

In Microsoft Windows and in Linux, managing configuration data has grown to become a huge problem. 

In Windows this is stored in the registry, which is hierarchical database.  In Linux, this is stored in plain text files, which is something of a problem as it is easy for these to be incorrectly formatted.  On the other hand, the Windows registry is also a problem, for it is a database that fails to scale.  We need a database that can efficiently handle a hierarchical tree containing a very large number of very small flat tables - the file system already provides hierarchical trees, and Sqllite provides flat tables, so the quick and dirty way to do that is the way Linux already does it. 

But both systems suffer from the big problem that any program can write to the configuration data of any other program, and no program can protect its configuration information from being changed into an inconsistent state.  It is very common to make a mistake editing the configuration data, and suffer mysterious and dreadful consequences. 

So each package should get its own private data spaces, in which it stores data both as plaintext, and as Sqlite databases. 

We want fine grained control over access to these data spaces, so that an installed package can prevent them being changed in surprising ways or to inconsistent states. 

Home

pseudo persistent process private mutable data, only accessible by single process that is an instance of the correct program of the package

Tmp

non persistent mutable data, only accessible by that process, deleted when the non persistent process ends.

Etc

read only data available to all instances of a program from the package run by the same user as the current instance. Editable only by that user through a facility provided by the package, which locks normal programs of the package from reading material subject to change.

Root

read only data available to all instances of a program from the package on a given machine. Editable only by root through a facility provided by the package, which locks normal programs of the package from reading material subject to change.

In all cases, only package code should be able to change the data, though this may well mean that the standard configuration editing tool sends messages to package code, which package code can then act on such messages in the standard generic fashion, or ignore such messages, or reject some change messages with an error message. 

These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License