100 lines
3.4 KiB
HTML
100 lines
3.4 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en"><head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
p.center {text-align:center;}
|
||
a:hover {
|
||
color: #FF0000;
|
||
}
|
||
dl {
|
||
margin-left: 2.5em;
|
||
padding-left: 0;
|
||
margin-top: 0pt;
|
||
margin-bottom: 20pt;
|
||
padding-top: 0pt;
|
||
padding-bottom: 0pt;
|
||
top: 0pt;
|
||
bottom: 0pt;
|
||
}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>Configuration Data in a Safe Operating System</title></head>
|
||
<body>
|
||
|
||
<p><a href="./index.html"> To Home page</a> </p>
|
||
|
||
<h1>Configuration Data in a Safe Operating System</h1>
|
||
|
||
<p>In Microsoft Windows and in Linux, managing configuration data
|
||
has grown to become a huge problem. </p><p>
|
||
|
||
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.
|
||
</p><p>
|
||
|
||
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. </p><p>
|
||
|
||
So each package should get its own private data spaces,
|
||
in which it stores data both as plaintext, and as
|
||
Sqlite databases. </p><p>
|
||
|
||
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. </p> <dl><dt>
|
||
|
||
Home</dt><dd> pseudo persistent process private
|
||
mutable data, only accessible by single process
|
||
that is an instance of the correct program of the
|
||
package</dd><dt>
|
||
|
||
Tmp</dt><dd> non persistent mutable data, only
|
||
accessible by that process, deleted when the non
|
||
persistent process ends.</dd><dt>
|
||
|
||
Etc</dt><dd> 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. </dd><dt>
|
||
|
||
Root</dt><dd>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.</dd> </dl><p>
|
||
|
||
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. </p>
|
||
|
||
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
||
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
Commons Attribution-Share Alike 3.0 License</a></p>
|
||
</body></html>
|