Daylight Database Security, Caching, and Other Issues
An updated summary of relevant theory and administration.
The following topics have been chosen because there is a great deal of
flexibility in the configuration of Daylight servers and databases in
these areas. Hence, there are also many choices to be made by database
administrators to optimize performance, security, and convenience of
their Daylight software installation. Here we try to provide some
straightforward background and guidance to assist in these choices.
Security is control over access to data and other resources.
The Daylight system is concerned with:
The security of the system is dependent upon the underlying filesystem
permissions. For this reason we recommend that all software and
databases are owned by a single user "thor", and that the servers
are run by thor. Other users should be able to run the client
- Access to the Daylight servers (Thor, Merlin, Daytools).
- Access to data in databases.
Server access is controlled by a system of users and passwords.
This user list is completely separate from the list of unix
users. However, some Daylight client programs (e.g., xvmerlin)
may use the unix username as a "guess" to attempt server access.
The list of Daylight users and passwords is contained in the
file dy_passwords.dat, located in $DY_ROOT/etc by default or
specified by environment variable DY_DATABASE_PASSWORDS_FILE.
Although this file may be easily edited by hand, it is designed
to modified by inputs to the sthorman program.
Example dy_passwords.dat file:
Note: if desired, a separate passwords file may be used by the
DayToolserver, specified by the environment variable
Each database has three passwords:
- Read: read-only access
- Write: read/write access
- Executive: read/write access, plus database administration
privileges, such as "thorchange" and "thordestroy."
In practice, read/write access is sufficient to severly or completely
corrupt a database. Thus, the executive password may be most useful
for preventing unauthorized, accidental, inconvenient or catastrophic
"boo-boos", while write password is responsible for securing the data
Other Security Tricks
- If a directory is not included in DY_DATABASE_PATH, it will
not be listed by "thorls" or other clients. Thus, it is
somewhat hidden. However, it may still be accessed by
specifying the exact path.
Caching is using RAM instead of disk to improve speed and efficiency.
Daylight caching may be specified by the configuration of a database,
or initiated by client request if allowed by configuration.
Caching configuration specifications are normally made by
thormake, thorchange, or sthorman.
The option CACHE_LEVEL is ignored unless CACHE_WHEN is ALWAYS.
Disable caching; all data remain in the disk files.
Ignore caching requests from Thor clients.
Cache if, when, and as specified by a Thor client.
(Synonymous with "ON_REQUEST".)
Read hashtable from RAM, write to disk (and RAM).
Read and write hashtable in RAM. Disk synced when necessary.
Read entire database from RAM, write to disk (and RAM)
Read and write entire database in RAM. Disk synced when necessary.
By default, both primary data and cross-references are cached.
However, we can select one or the other only. Note that both
primary and xref data have separate hash tables and datafiles.
Possible values in the .THOR header file:
cache level: NEVER
cache level: ON_REQUEST
cache level: ALWAYS WRITETHRU
cache level: ALWAYS WRITETHRU XREFS_ONLY
cache level: ALWAYS WRITETHRU DATA_ONLY
cache level: ALWAYS READWRITE
cache level: ALWAYS READWRITE XREFS_ONLY
cache level: ALWAYS READWRITE DATA_ONLY
cache level: ALWAYS WRITETHRU_ALL
cache level: ALWAYS WRITETHRU_ALL XREFS_ONLY
cache level: ALWAYS WRITETHRU_ALL DATA_ONLY
cache level: ALWAYS READWRITE_ALL
cache level: ALWAYS READWRITE_ALL XREFS_ONLY
cache level: ALWAYS READWRITE_ALL DATA_ONLY
Another choice to be made is whether to cache the "regular"
database, or perhaps the indirect database. For databases where there
are a large number of indirect references per TDT, caching the
indirect database can provide the greatest performance gains.
OTHER DATABASE CONFIGURATION ISSUES
- "Holding" a database keeps it open when no clients are using it.
This improves performance of frequently-opened and cached
databases. Holding is independent from caching level.
- With record-locking enabled, clients can lock individual records for
exclusive access, "commit" and "rollback" changes, and unlock
Header (.THOR) file entry:
tdt locking: TRUE (Either present or not.)
- Databases can be configured writable (by default) or readonly.
Readonly databases do not create lockfiles, thus they are useable
from CDROM. Also it is possible to open one database with two
Header file entry:
read only: TRUE (Either present or not.)
JJY / 10-Dec-1996