Three steps are involved in the setting up of system and data access control:
The creation of guards (see "Guards administration").
The definition of access conditions.
Linking the guards with the objects to be protected (see below).
Defining access conditions
Access conditions are specified with the /ADD-ACCESS-CONDITIONS command, modified with the /MODIFY-ACCESS-CONDITIONS command, displayed with the /SHOW-ACCESS-CONDITIONS command and removed again with the /REMOVE-ACCESS-CONDITIONS command.
The /SHOW-ACCESS-ADMISSION command gives users information about the conditions they must satisfy in order for them to be allowed access to a particular object.
The access conditions can be specified under the following aspects:
Access is to be globally permitted or forbidden.
Access is to be granted only under specific circumstances:
Period (time, date, day of week) - it is possible to specify a list of periods when access is permitted or forbidden. These periods are logically ORed.
Privilege (access may take place only with certain privileges) - it is possible to specify a list of privileges for which access is permitted or forbidden. The privileges in this list are logically ORed.
Program (access may take place only via a particular program, in which case GUARDS checks whether the program is both loaded and has assumed control). The program names in the list are logically ORed.
These access conditions can be defined at various levels for the various subject types (USER/GROUP/OTHERS/ALL-USERS). Further details of the evaluation logic for the subject types can be found in section "Defining access conditions"
Linking with the objects to be protected
In order to protect an object against unauthorized access with the aid of GUARDS, it is necessary to establish a link between the object to be protected and the guards in which the corresponding access conditions are defined. This means: the object owner notifies the object management system of the guards which contain the access conditions. The commands and program interfaces which are provided by the different object management systems for linking their objects to guards are described in the sections “Protecting ...”, see below.
Since a link is known only to the object management systems in question but is not contained in the guards, one guard can be used to protect a number of different object types (such as files, library members, job variables etc.).
A link can only be established or removed by the owner or co-owner of the object, but not by the owner of the guard (insofar as the two owners are not identical).
Since an object and the guards linked to it can have different owners, special care should be taken to ensure when deleting guards that the links between the guards and the objects they were protecting are also removed by the object owners in question. This is done in the case of a file for example by specifying:
/MODIFY-FILE-ATTRIBUTES <filename>, PROTECTION=(GUARDS=*NONE)
.Until a link with a guard which has already been deleted is actually removed, not even the object owner can access the linked object.
Protecting files, job variables and library members
When GUARDS is employed, DMS, JVS and LMS will allow only those access operations which are explicitly permitted. Unlike SHARE/ACCESS, guards do not confer the read privilege when the write privilege is granted.
For files, the guard name to be used to provide protection is specified by means of the PROTECTION operand in the /CREATE-FILE or /MODIFY-FILE-ATTRIBUTES command. Further notes on setting up access protection for files can be found in the “Introductory Guide to DMS” [6].
For library members, the link between the guard name to be used and the library member is established by means of the //CREATE-ELEMENT or //MODIFY-ELEMENT-
PROTECTION command. Further notes on setting up access protection for library members can be found in the “LMS” manual [23].
For job variables, the guard name to be used to provide protection is specified by means of the PROTECTION operand in the /CREATE-JV or /MODIFY-JV-ATTRIBUTES command. Further notes on setting up access protection for job variables can be found in the “JVS” manual [32].
Protecting storage classes
For storage classes, the guard name to be used to provide protection is specified by means of the PROTECTION operand in the /CREATE-STORAGE-CLASS or /MODIFY-STORAGE-CLASS command. Further notes on setting up access protection for storage classes can be found in the “SMS” manual [33].
Protecting HSMS management classes
For HSMS management classes, the guard name to be used to provide protection is specified by means of the PROTECTION operand in the HSMS statements //CREATE-MANAGEMENT-CLASS or //MODIFY-MANAGEMENT-CLASS. Further notes on setting up access protection for HSMS management classes can be found in the “HSMS” manual [11].
Group assignment
If an attempt is made to access files and job variables which are protected by BACL, certain users can be treated as if they were group members. This group assignment is defined in the BASIC-ACL-ACCESS operand of the commands ADD-USER-GROUP and MODIFY-USER-GROUP.
Interactive and batch access
Access to a user ID can be controlled by a separate guard depending on the access mode employed. The guards are assigned by means of the following operands of the commands SET-LOGON-PROTECTION and MODIFY-LOGON-PROTECTION.
DIALOG-ACCESS
BATCH-ACCESS
POSIX-RLOGIN-ACCESS
POSIX-REMOTE-ACCESS
NET-DIALOG-ACCESS
Of special importance is the ability to protect personal user IDs (see section "Personal identification" by means of guards.
Protecting terminal sets
In the case of access protection with terminal sets, you can control access by means of a guard as well. You specify this by using the GUARD-NAME operand of the CREATE-TERMINAL-SET command or the MODIFY-TERMINAL-SET command.