HP 3000 Manuals HP 3000 Manuals
Protecting the Database
TurboIMAGE/XL prevents unauthorized persons from gaining access to the
database. It provides external protection through the MPE/iX privileged
file, account, and group constructs and, in addition, provides the
database designer and database manager with methods to refine security
within the database.
Privileged File Protection
All TurboIMAGE/XL database files are privileged files. (Refer to the
MPE/iX Intrinsics Reference Manual for a description of the MPE/iX
privileged file capability.) Access by unprivileged processes or through
most MPE/iX file system commands is not allowed. Therefore,
non-privileged users are prevented from accidentally or deliberately
gaining access to the database.
Using MPE/iX commands that permit copying TurboIMAGE/XL files to tape
represents a potential breach of database privacy, and their use should
be controlled. In particular, anyone who uses the MPE/iX SYSGEN, STORE,
or RESTORE commands should notify the database manager. The SYSGEN and
STORE commands permit system supervisors, system managers, and other
privileged users to copy files to tape. The RESTORE command can purge
and replace a database file with a different file from tape if the files
have the same name.
Account and Group Protection
To gain access to a TurboIMAGE/XL database, you must be able to access
the files in the account and group in which the database resides. The
system manager and account manager administer the security levels for
accounts and groups. [REV BEG] The system manager creates accounts, and
either the system or account manager creates new groups and users.[REV
END]
The system and account managers can prevent members of other accounts
from accessing the database by specifying access as user type AC (account
member) for the account and group containing the database. They can
prevent users who are members of the account, but not of the group,
containing the database from accessing it by specifying GU (group user)
for the group access. On the other hand, they can allow access from
other accounts by specifying user type ANY at both the account and group
levels.
Defining Database Security
After the data items, data sets, and paths for the database have been
defined, database security can be addressed. Defining security involves
the following two steps:
1. Defining user classes and passwords
2. Setting up read and write class lists
User Classes and Passwords.
Consider who will be using the database. Do all users perform the same
tasks or are the tasks varied? Do all users need to read and update the
same data items? The answers to these questions will help define how
many user classes are needed.
For each type of user, define a password and user class number. Each
user class is identified by an integer from 1 to 63. Because more than
one user at a time can use the same password, you may only need to define
a few passwords for your database. You may want to relate the user class
number to the user's job position; for example, the ORDERS database is
defined with these user classes and passwords:
User Class Password
11 CREDIT;
12 BUYER;
13 SHIP-REC;
14 CLERK;
18 DO-ALL;
When you initiate access to the database, you must supply a password to
establish the user class. If the password is null or does not match any
password defined for the database, the user class assigned is zero which
has read access to unprotected data sets.
NOTE Because user class 0 has read access, calls requiring read access
to an item or set will complete successfully (condition word 0)
even if an invalid password was supplied.
The database creator does not need to supply a password. If you are the
logged on as the database creator and enter a semicolon in place of a
password, you are granted full access to all data sets in the database.
TurboIMAGE/XL uses the number 64 to identify the database creator and the
numbers 0 to 63 to identify all others.
Read and Write Class Lists.
After you have defined user classes and passwords, define the type of
access allowed by each password to the data items and data sets in the
database. Establish security in the schema by including or excluding the
user class numbers in the read or write class list of the data items and
data sets, or by omitting a user class list entirely. Omitting a user
class list (known as an absent list) has the same effect as including all
user classes, including user class 0, in the read class list.
The combinations of the data set and data item user class lists result in
one of the following five types of access:
* Write access
* Update access
* Read access
* No access
* Creator-only access
Write Access.
A user class that has write access can add entries to or delete from the
data set. Write access means that update and read access are also
granted, and is sometimes referred to as full data access. To grant
write access to a user class for a data set, include the user class
number in the write list of the data set. The specified user class then
needs to open the database using mode 1, 3, or 4 to take advantage of
write access. The user class is ignored if it appears in the user class
lists of data items that belong to the data set because write access to a
user class at the data set level supersedes that at the item level.
NOTE Database access modes 2, 5, 6, 7, and 8 do not allow write access.
Programs that open the database in these modes must pass data set
and data item level security. For additional information, refer to
chapter 4 and to "Database Access Modes and Data Set Write Lists"
later in this chapter.
Update Access.
A user class that has update access can change the values of a particular
data item in an existing data entry. However, the user class cannot add
or delete entries from the data set. Update access means that read
access is also granted. To grant update access to a user class for a
data item, include the user class in the read list of the data set and in
the write list of the data item. The specified user class then needs to
open the database in mode 1, 2, 3, or 4 to take advantage of this type of
access. The user class can have update, read, or no access to other data
items in the data set depending on the user class lists of the other data
items.
NOTE TurboIMAGE/XL provides an option called critical item update
(CIUPDATE) which lets you update the values of detail data set
search and sort items if the database access mode is 1, 3, or 4 and
if permitted for the current process. You can restrict update of
these data items by assigning read-only access at the set level and
controlling write or update access at the item level. See chapter
4 for more information on CIUPDATE.
Read Access.
A user class that has read access can only view the values of a
particular data item. To grant read access to a user class for a data
item, include the user class in the read class list of the data set and
in the read class list of the data item. This user class can have
update, read, or no access to other data items in the data set depending
on the user class lists of the other items.
No Access.
A user class that has no access cannot read data item values. No access
to a user class can be defined for an entire data set or for specific
data items in a data set. Specify no access for a user class to an
entire data set by excluding the user class from the read and write class
lists of the data set. To allow no access to a specific data item,
include the user class in the read class list of the data set and exclude
the user class from the read and write class lists of the data item.
Note that the read or write portions of the user class list can be left
empty; this is known as a null list. In the example below, only the
database creator has write access:
(11,14/) The write class list is null.
Creator-Only Access.
If you specify an empty data set user class list, as shown below, only
the database creator has access:
(/) This is called a null list.
Sample Read and Write Class Lists.
Table 2-1 contains sample lists for the CUSTOMER data set and
CREDIT-RATING data item in the ORDERS database.
Table 2-1. Sample Read/Write Class Lists
----------------------------------------------------------------
| | | |
| | Read Class | Write Class |
| | List | List |
| | | |
----------------------------------------------------------------
| | | |
| CUSTOMER (data set) | 11,14 | 11,18 |
| | | |
| CREDIT-RATING (data item) | 14 | 14 |
| | | |
----------------------------------------------------------------
Because a write class list of 14 implies that user class 14 is in the
read class list, the CREDIT-RATING read class list is redundant.
However, it could be included as a reminder in the schema of the total
capability granted to user class 14.
Table 2-2 later in this chapter contains examples of the effects of
read and write class lists. Note that the examples take into account how
the database access mode affects the data set write list.
Null and Absent Lists.
A distinction is made between the absence of both read and write class
lists (which by default allows read access) and a null list. When you
specify the lists in the schema, they are enclosed in parentheses and
separated by a slash, for example, (11,14/15). A null list can be one of
the following:
(/) Both read and write class lists are null.
(11,14/) The write class list is null.
Because the existence of a write class list implies a read class list,
even if no user classes are listed in the read list and at least one user
class is specified in the write list, the read class list is not
considered null.
An absent list and the following null write list, in which the read
portion contains all user classes and the write portion is null, yield
the same result:
(0,1,2,3,...63/)
The effect of null and absent lists is illustrated in Figure 2-8
later in this chapter.
Database Access Modes and Data Set Write Lists
Before you can gain access to a database, you must open it specifying a
password that establishes your user class number and an access mode that
defines the type of database tasks you want to perform. Access modes are
described in chapter 4 with the instructions for opening a database. At
this time it is necessary only to note that some of the eight available
access modes do not allow write or update access even if the user class
is allowed these capabilities through the user class lists. If the
database is opened in access mode 2, 5, 6, 7, or 8, all data set write
class lists are merged into the read class lists, and the merged read
class lists are used for all data sets.
Granting a User Class Access
Figure 2-7 and Table 2-2 illustrate the use of read and write
class lists from two different perspectives. Figure 2-7 shows what
capability user class 11 has if it appears in the lists as shown. The
same rules apply to any user class. The access mode must be as
indicated.
![[]](../../pic3k/M012332/FFN123c50.gif)
Figure 2-7. Granting Capability to User Class 11
A null read and write class list can be used by the database creator at
the data set level to deny access to the data set by all user classes;
that is, only the database creator will be able to use the data set.
Table 2-2 presents the same rules organized by the task that the user
class is to perform. It lists the required access modes and the security
rules at both the data set and data item level. For simplicity, assume
there are always read and write class lists even if they are the default
lists (0, 1, 2,...63 /) resulting when the lists are omitted in the
schema (absent lists).
Table 2-2. Enabling a User Class to Perform a Task
-------------------------------------------------------------------------------------------------
| Task | Database Access | Data Set | Data Item |
| | Mode | Security Rules | Security Rules |
-------------------------------------------------------------------------------------------------
| Read Data Item | 1, 3, or 4 | User class must be in data | |
| | | set write list, or | |
- - - _____________________ - __________________ -
| | | User class must be in data | User class must be in read |
| | | set read list and pass data | or write list. |
| | | item security. | |
- - ___________ - _____________________ - __________________ -
| | 2, 5, 6, 7, or | User class must be in data | User class must be in read |
| | 8 | set read or write list and | or write list. |
| | | pass data item security. | |
-------------------------------------------------------------------------------------------------
| Update Data | 1, 3, or 4 | User class must be in data | |
| Item | | set write list, or | |
- - - _____________________ - __________________ -
| | | User class must be in data | User class must be in write |
| | | set read list and pass data | list. |
| | | item security. | |
- - ___________ - _____________________ - __________________ -
| | 2 | User class must be in data | User class must be in write |
| | | set read or write list and | list. |
| | | pass data item security. | |
-------------------------------------------------------------------------------------------------
| Add or Delete | 1, 3, 4 | User class must be in data | |
| Data Entries | | set write list. | |
-------------------------------------------------------------------------------------------------
In summary, the database designer can grant access to a data set in the
following ways:
* Specify the user class number in the data set read class list (or
omit both read and write lists entirely). This grants the user
class read access to the data set that is controlled at the data
item level as described later. If both read and write class lists
are absent, the user class is granted this type of access because
the lists are (0,1,2,...63/) by default. Opening the database in
access mode 2, 5, 6, 7, or 8 is the same as specifying the user
class number in the data set read class list only.
* Specify the user class number in the data set write class list.
If the database is opened in access mode 1, 3, or 4, this grants
the user class complete access to the data set. Users in this
class can add and delete entries, update the value of any data
item, and read any item, regardless of the data item read and
write class lists. Master data set key it em values cannot be
updated. Detail data set search or sort item values can be
updated if permitted by the critical item update (CIUPDATE) option
settings for the database and the current process. A user class
number must be in the data set write list in order to add and
delete entries. For information about critical item update
(CIUPDATE), refer to chapter 4.
* Exclude the user class number from both the specified read and
write class lists of the data set. This denies the user class any
type of access to the data set.
Assuming the database designer has granted only read access at the data
set level as summarized above, control at the data item level is
established in the following ways:
* Specify the user class number in the data item read class list (or
omit both read and write class lists entirely). This grants the
user class read access to the data item.
* Specify the user class number in the data item write class list.
This grants the user class the ability to update or change the
data item value. Master data set key item values cannot be
updated. Detail data set search or sort item values can be
updated in database access mode 1, 3, or 4 if permitted by the
critical item update (CIUPDATE) option settings for the database
and the current process. Because the user class is implied to be
in the read class list, the user class can also read the item. A
user class number must be in the data item write list in order to
update the value.
* Exclude the user class number from both the specified read and
write class lists of the data item. This denies the user class
any type of access to the data item.
The protection of data set and data item values is designed so that the
database designer must explicitly specify the user class number to allow
that class to make any type of change to the database. Read access can
be granted by default in some situations, for example, by omitting the
lists entirely (also known as absent lists). To deny read access to a
data set or data item, the database designer must specify a list and
deliberately exclude the user class number.
Figure 2-8 provides a security flowchart. The database has been
opened in modify access mode 1, 3, or 4; these are the only allowable
access modes for CIUPDATE which allows update of detail data set search
and sort items. As you read the flowchart, consider the following
examples based on the sample ORDERS database:
* Only user classes 11 and 18 can add and delete CUSTOMER data
entries because these are the only user class numbers in the data
set write list as shown earlier in Table 2-1 . To do so, they
must open the database in access mode 1, 3, or 4.
* User class 14 can update the CREDIT-RATING data item in the
CUSTOMER data set because it is in the data item write list and
the data set read list. To do so, the database must be opened in
access mode 1, 2, 3, or 4.
![[]](../../pic3k/M012332/FFN133c50.gif)
Figure 2-8. Security Flowchart
Table 2-3 contains more illustrations of the effects of read and
write class lists. These are general examples that are not based on the
ORDERS database shown in this manual.
Note that these examples take into account the effects of the access mode
in which the database is opened. The database creator and user class 9
(in access mode 1, 3, or 4) have complete access to data set 1, but only
the creator has complete access to data set 2. Complete access includes
the ability to add and delete entries, read all items, and update the
values of all items with the following exceptions. Master data set key
item values cannot be updated. Detail data set search and sort item
values can be updated only in database access mode 1, 3, or 4, and only
if permitted by the CIUPDATE option settings for the database and the
current process. Note that except where user class 9 is specifically
identified in a read and write class list, user class 9 has complete
access to data set 1 only when the database access mode is 1, 3, or 4.
Table 2-3. Sample Read and Write Class Lists
-------------------------------------------------------------------------------------------------
| | | | |
| Data Item | Read/Write List | Item Read Access | Item Update Access* |
| | | | |
-------------------------------------------------------------------------------------------------
| |
| Data Set 1 (0,18,13/9) |
| |
-------------------------------------------------------------------------------------------------
| | | | |
| A | | 0,13,18,9 | 9* |
| | | | |
| B | (13/) | 13,9* | 9* |
| | | | |
| C | (/) | 9* | 9* |
| | | | |
| D | (/19) | 9* | 9* |
| | | | |
| E | (18/13) | 13,18,9* | 13,9* |
| | | | |
| F | (/13,18) | 13,18,9* | 13,18,9* |
| | | | |
| G | (12/0) | 0,9* | 0,9* |
| | | | |
| H | (13/) | 13,9* | 9* |
| | | | |
-------------------------------------------------------------------------------------------------
| |
| Data Set 2** |
| |
-------------------------------------------------------------------------------------------------
| | | | |
| A | | 0,1,...,63 | |
| | | | |
| I | (13/9) | 13,9 | 9 |
| | | | |
-------------------------------------------------------------------------------------------------
| |
| * User has access only if the database access mode is 1, 2, 3, or 4. For access |
| modes 1, 3, and 4, the CIUPDATE option settings for the database and the current |
| process need to permit updates of any items that are detail data set search or sort |
| items. |
| |
| * User has access only if the database access mode is 1, 3, or 4. For update access, |
| the CIUPDATE option settings for the database and the current process need to |
| permit updates of any items that are detail data set search or sort items. |
| |
| ** Data set 2 has an absent list. The database creator has full access to the data |
| set if the database access mode is 1, 3, or 4. If the database is opened in access |
| mode 2, the user has item update access to all items, except master data set key |
| items or detail data set search and sort items even if the CIUPDATE option settings |
| for the database and the current process permit updates of search and sort item |
| values. |
| |
-------------------------------------------------------------------------------------------------
User Classes and Locking
TurboIMAGE/XL does not consider user classes when locking a database
entity. Any data set or any data item can be referenced in a lock
request by any user of a database regardless of his or her user class.
Protection in Relation to Library Procedures
All access to a database is achieved through database control blocks that
reside in privileged MPE/iX files which are not directly accessible to
database users. Because no user process can read or modify these control
blocks, TurboIMAGE/XL guarantees protection of the database from
unauthorized programmatic access. Refer to the detailed description of
these control blocks in chapter 10. For more information about MPE/iX
files and privileged mode, refer to the MPE/iX Intrinsics Reference
Manual.
All TurboIMAGE/XL library procedures that structurally modify the
database execute in critical mode. This defers any requested process
termination while modifications are in progress. If any file system
failures occur during such database modification, TurboIMAGE/XL causes
process termination because the database integrity is questionable.
The Database Buffer Area Control Block (DBB) contains pointers to the
data set blocks that are used to transfer data (see chapter 10 for
additional information). All data set blocks whose contents are changed,
reflecting a modification of the database, are always logged by an
internal MPE/iX service called Transaction Management (XM) before the
library procedure returns to the calling program. This guarantees
database integrity despite any program termination that might occur
between successive procedure calls. However, deferred output (AUTODEFER)
allows the user to override this scheme. When AUTODEFER is enabled, the
database does not use MPE/iX Transaction Management. Instead, AUTODEFER
uses the MPE/iX file system default recovery mode. This mode keeps data
pages in memory for as long as possible until file close time. In this
mode, a system failure can cause the loss of database integrity. For
more information about AUTODEFER, refer to the >>ENABLE command of DBUTIL
in chapter 8.
Protection Provided by the TurboIMAGE/XL Utilities
The TurboIMAGE/XL utilities perform various checks to ensure database
integrity:
* They acquire exclusive or semi-exclusive access to the database
being processed. (Chapter 4 contains more information about types
of access in the discussion of opening a database.)
* Only the database creator or a user supplying the correct
maintenance word can execute the utilities. The database creator
defines the maintenance word when the database is created with the
DBUTIL utility (refer to chapter 8). In addition, anyone without
system manager (SM) capability intending to use the DBUTIL >>SHOW
command or anyone running the utilities other than DBRECOV must be
logged on to the group in which the database resides (refer to
chapter 8).
If no maintenance word is defined, only the database creator can
execute the utilities. The exception to this rule is that a user
with system manager (SM) capability can use the DBUTIL >>SHOW
command on any database without having to supply the maintenance
word.
* Unrecoverable disk or tape problems are treated as functional
failures rather than limited successes and result in program
termination.