1
0
forked from cheng/wallet
wallet/docs/safe_operating_system_config_data.html
2022-02-18 13:33:27 +10:00

101 lines
3.4 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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>