data-base to which it applies. If we dumped the transaction log to another database or to the host, it must be first loaded.
IDM: Database Management
3 -11
10M Software Reference Manual Version 1.6 Britton-Lee Inc.
(1) open backup
(2) load transaction inventory newtrans from transl (3) open inventory
(4) range of n is newtrans
(5) audit (n.user, n.type, n.value)
where n.relid
=
rel_id("parts")Commands (1) and (2) load a copy of the transaction log into the "inventory" database. Then in (3) and (4) the audit report is retrieved. The requirements for backup and audit-ing are different and so it is necessary to move the log before retrieving the audit.
3.5. User Authentication and Protection
Authentication is the process of securely recognizing the identity of a user of the 1DM system. Once a user's identity has been authenticated, the 10M protection system takes over. The protection system determines what database, relations, views and stored commands a user may use.
3.5.1. User Authentication for the 10M
Users interact with a host computer which, in turn, interacts with the 10M database management system. In some environments, the host computer will authenticate the user (typically by asking the user for a login name and pass-word). In other environments, it is necessary for the 10M to authenticate the user. The designer of a database appli-cation has the choice of
1. Host computer user authentication 2. 10M user authentication
3. Both Host and IDM user authentication
This choice is based on whether a host computer is
"trustworthy" or "untrustworthy". A trustworthy host environment is one in which the host operating system authenticates the user and prevents the user from directly telling the IDM the user's identification. Examples of trustworthy systems are mainframes and minicomputers running multi-user operating systems. An untrustworthy host environment is one in which the user can directly communi-cate his identification to the 10M. Examples of untrustworthy systems are personal computers and computers connected over some networks. On untrustworthy systems, the user must supply the 10M a password in order to use the 10M.
Users are identified either by name or by number. Host computers are identified by number. These identifications are called:
IOM software Reference Manual Version 1.6 Britton-Lee Inc.
on host computer
3.5.1.1. Types of Hosts Using Authentication System
The method of user authentication is determined by the host type and the "login" relation on the IOM. There are four basic host types:
1. Trustworthy host with user numbers (examples:VAX/VMS, VAX/UNIX) 2. Trustworthy host with user names
(example:VM/CMS)
3. Untrustworthy host with user numbers (unlikely to be used by anyone) 4. Untrustworthy host with user names
(example:IBM PC, Ethernet based hosts with standard driver)
The IOM protection system requires knowing the hid and huid for every user. Accounting of user dbp usage in the
"account" relation of the "system" database also uses the hid and huid to identify every user. Host types 1 and 3 provide the hid and huid directly. For other host types, the huname must be translated to an huid. The "login" rela-tion in the IOM's "system" database provides this transla-tion. The "login" relation has the following attributes
login (type, hid, huid, huname, password, class) This relation is used to
1. translate hid, huname pair into huid (for host types 2 or 4)
2. verify passwords
(for host types 3 or 4) 3. provide password protection
(optional check for host types 1 or 2) 3.5.!.!.!. Trustworthy Host~ with User Numbers
If the host computer is trustworthy and provides the IOM with the user's huid, no entry is required in the 10g1n relation. If an entry is present, the user must match the specified password. The optional login entry gives the user additional protection. Someone must know the user's host password and the user's IOM password to use the IOM.
The BLI parallel and serial drivers for VAX/VMS and VAX/UNIX use this technique. Either VMS or UNIX authenti-cates the user and identifies the user with a 4 byte number.
The IDM "trusts" the number supplied by VMS or UNIX.
3.5.1.1.2. Trustworthy Hosts with User Names
If the host computer is trustworthy and securely pro-vides the IDM with the user's name, the IDM will look for an
IDM: Oatabase Management Updated March 1984 3 - 13
IDM Software Reference Manual Version 1.6 Britton-Lee Inc. use-ful in development environments.
3.5.1.1.3.
3.5.1.1.4. untrustworthy Host~ ~ith User Name~
If the host is untrustworthy, the user of the 10M must
10M Software Reference Manual Version 1.6 Britton-Lee Inc.
Hunames are untrustworthy by default.
3.5.1.3. Login Relation
"type", "hid", "huld", "huname" and "class" fields can be made readable if desired. The definition of the login disabling an account without deleting the tuple.
10M Software Reference Manual Version 1.6 Britton-Lee Inc. packet" (see section 6.3.1 "Communications Packets and Data Packets"). This packet is normally trustworthy since i t is considered trustworthy, as described above in the configura-tion secconfigura-tion. huname, any huname sent should be considered untrustworthy, since any huname sent will override the huid. By default, hunames are considered untrustworthy, as described above.
3 - 16 Updated March 1984 10M: Database Management
10M Software Reference Manual Version 1.6 Britton-Lee Inc.
Users sending trustworthy or untrustworthy log ins must have a type of "A" (all) or blank (uninitialized) in their login tuple. Users sending trustworthy logins may also have no login tuple at all or may have a type of "T" (trustworthy only) in their login tuple. A type "T" means the account may only be accessed if the login is trustworthy. This can
increase security for users sending trustworthy login ids.
The OBA may turn off a user's account by setting the
1DM Software Reference Manual Version 1.6 Britton-Lee Inc.
For any of the above matching tuples, the login tuple and the login id sent from the host must meet the require-ments of a valid password and type, as described above; oth-erwise the user is denied access to the 10M.
3.5.1.7. Error ~essage Retu£~~~ ~ Authentication System Whenever users are denied access to the IDM, the login relation. Hosts sending trustworthy hunames will need to use this feature when installing the 10M.
3.5.2. Protection For Individual Databases
- -
database called "demo", three events would happen:1. An entry would be placed in the "databases"
IDM Software Reference Manual Version 1.6 Britton-Lee Inc.
1---1
To enable another user to be the DBA of "demo", a tuple is appended to "host_users", for example,
append host_users(hid=1,huid=10,uid=2)
IDM Software Reference Manual Version 1.6 Britton-Lee Inc. override the normal protection system with command-option 14. with this option set, the DB.~ of the system database
IDM Software Reference Manual Version 1.6 Britton-Lee Inc. instance, if "george" accesses the relation "parts", the permissions for "parts" are checked to se@ if "ge~(ge" has read permission for "parts".
However, when a command is sent to the IDM, the name of the user issuing the command is not necessariiy supplied by the host system. Instead, the following identification 1S
provided: a host ID (hid), which uniquely identifies to the hid/huname pair 5l5/"kinggeorge". For each command he sends, the 10M must associate that pair correctly with the
1~~ Software Reference Manual Version 1.6 Britton-Lee Inc.
"login" relation is a system relation which exists only in the system database (see Authentication above). The
"host users" and "users" relations are system relations, and are present in each database.
host users (sl, hid, huid, uid) users (stat, id, name, gid, passwd)
For the system database, "users" and "host users" are initially empty. ~his means that anyone who opens the data-base will be the DBA. The first person opening the system database should be careful to add a tuple to "host users" to
make them the DBA.
-For user databases, "host users" is initialized so that the creator of the database-is the DBA for that database.
The "users" relation is initially empty.
The nB.~ must fill in the "host users" relation, supply-ing the host ID and host user ID f~r each user, and assign-ing the uid. Only users with a tuple in the "host users"
relation will be allowed to open that database. rrhe "'users"
relation must also be updated, filling in the applicable information.
Continuing the example of "george", to allow him to communicate with the IDM from the C host, the following update must be made to the login relation in the system database:
append to login (hid
=
515,huname
=
"kinggeorge", huid = 464)This single tuple is required only for "george's" account on the C host, which sends hunames to identify users. This tuple maps the huname "kinggeorge" on the C host (hid 515), to the huid 464. The huid 464 is not used in communicating with the host computer. No entry is required for his accounts on the other hosts, which send huids rather than hunames. ~he DBA of the system database is responsible for maintaining the "login" relation.
To allow "george" access to any given database, the following updates must be made to the "host users" relation for that database:
3 - 18.4 Updated March 1984 IDM: Database Management