The following access attributes can be controlled for a job variable (the name(s) of the protection attribute(s) is (are) shown in the parentheses):
Users or user groups with access (shareable, multi-user access)
Read and/or write authorization, possibly separated according to access privileges (type of access, multi-user access)
Passwords for access (passwords)
Limitation (with respect to time) of the access (retention period)
Protection | Protection capabilities | Granularity of access privileges |
GUARDS  |
| Individual access profiles  |
Basic ACL  |
| Access profiles for groups  |
Default protection | Default access control
Additional protection capabilities
| Owner or all |
Table 4: Overview of protection capabilities for a job variable
The protection capabilities for a job variable are arranged on the three default protection levels (lowest level), basic ACL and GUARDS (highest level) (see table 4). The strongest active protection mechanism always applies for the protection of a job variable.
The use of passwords and the retention period (release date) is independent of the active protection mechanism, i.e. it is also possible for basic ACL and GUARDS. Access control (shareability and type of access) are further refined for these two protection mechanisms by creating three groups (OWNER, GROUP and OTHERS) for basic ACL and by creating access profiles for individual users for GUARDS.
Coexistence of the access mechanisms
Figure 1: Hierarchy of protection mechanisms for job variables
figure 1 clearly shows that the higher protection levels completely include the functionality of the levels below them.
The following rules apply where standard access control (USER-ACCESS, ACCESS), basic ACL as well as guards are used:
The values of the USER-ACCESS or ACCESS operand are entered in the catalog regardless of the fact that a higher-level protection mechanism (basic ACL or guards) may currently be in effect. If this is the case, the entries will not be evaluated until the higher-level protection mechanism is deactivated.
The BASIC-ACL operand sets the BASIC-ACL indicators in the catalog entry for the job variable, regardless of whether the job variable is protected by basic ACL or a higherlevel protection mechanism (guards). If a higher-level protection mechanism is active, the entries will not be evaluated until the higher-level protection mechanism is deactivated.
Default access protection
The default access control mechanism provides the protection attributes type of access and shareable. In addition, a retention period and password protection can be specified for a job variable in the default access protection (but also for basic ACL and GUARDS).
Type of access
A user can specify which type of access to a job variable he wants to permit using the operands of the CREATE-JV and MODIFY-JV-ATTRIBUTES commands.
ACCESS=*BY-PROTECTION-ATTR | The type of access is irrespective of the value of the operand PROTECTION-ATTR (see section “Default protection (user defined default values)”) |
ACCESS=WRITE | Read and write access is permitted |
ACCESS=READ | Read access is permitted |
At the macro level (CATJV macro) the operand value PROTECT=DEFAULT corresponds to the operand value ACCESS=*BY-PROTECTION-ATTR for the commands. The PROTECT operand refers not only to the type of access, but to all protection attributes. The operand values for read and write access are identical to those of the command operands.
Shareable
In the CREATE-JV and MODIFY-JV-ATTRIBUTES commands you specify which user IDs can access the job variable with the previously assigned access types with the USER-ACCESS operand (shareability):
The access irrespective of the value of the
USER-ACCESS=*BY-PROTECTION-ATTR | operand PROTECTION-ATTR (see section “Default protection (user defined default values)”) |
USER-ACCESS=*OWNER-ONLY USER-ACCESS=*ALL-USERS | Only the JV owner has access All user IDs have access |
At the macro level (CATJV macro) the operand values SHARE=NO / YES correspond to the values USER-ACCESS=*OWNER-ONLY/ *ALL-USERS.
Retention (protection) period
When a retention period is specified a job variable can be protected against changes and deletion for a specified period of time.
When the job variable is created, the current date is entered in the EXPIR-DATE output field of the SHOW-JV-ATTRIBUTES command by default. This date is then updated automatically when the contents of the job variable are changed.
You can specify for how many days from the current date the job variable will be protected from changes and deletion in the RETENTION-PERIOD operand using the command MODIFY-JV-ATTRIBUTES. When a retention period is specified, the number of days specified is added to the current date. The date (in EXPIR-DATE) now shows when the job variable will be able to be changed again.
The entry in the EXPIR-DATE output field remains unchanged until the retention period expires. After that, it is automatically modified to reflect the current date when the contents of the job variable are changed.
At the macro level (CATJV macro) the operand RETPD correspond to the operand RETENTION-PERIOD.
Password protection
Furthermore, you can make access to a job variable dependent upon the knowledge of a password.
A read password can be defined in the CREATE-JV or MODIFY-JV-ATTRIBUTES command in the operand READ-PASSWORD and a write password can be defined in the WRITE-PASSWORD operand.
The value YES in the job variable entry in the READ-PASS and WRITE-PASS fields shows that a read or write password has been defined. If no password is defined, then the value is NONE.
A new job variable is not protected by a password by default.
The required password must be entered in the password table of the entry with the ADD-PASSWORD command before accessing the job variable. This entry is valid until the job is completed. In some commands the password is specified in the PASSWORD or
JV-PASSWORD operand. Access is only authorized then when the command is executed. If a password is defined, then this password must be specified by all users who do not have system administration privileges, even when the protection attributes are to be changed with the MODIFY-JV-ATTRIBUTES command.
Password protection | Additional | Required specification for | ||
READ-PASS | WRITE-PASS | Read access | Write access | |
NONE | NONE | No protection | None | None |
YES | NONE | Read access | Read password | Read password |
NONE | YES | Write access | None | Write password |
YES | YES | Read access | Read or write | Write password |
Table 5: Password protection combinations and specifications for read or write access
When an attempt is made to access a job variable without the required password, then the non-privileged user is penalized with a time penalty. The duration of the time penalty depends on the setting for the system parameter PWPENTI and can have a value from 0 to 60 seconds. The user cannot input data during this time.
In the SHOW-JV, MODIFY-JV, MODIFY-JV-CONDITIONALLY, MODIFY-MONJV, DELETE-JV commands and the corresponding macros the password can still be specified in the command (PASSWORD operand). When the wrong password is entered, a check is made to see if the password has already been entered in the password table. If the password is not in the table, then the access attempt is an unauthorized attempt.
If this is not the case, then the access is authorized and the command is executed.
At the macro level (CATJV macro) the operand values RDPASS and WRPASS correspond to the READ-PASSWORD and WRITE-PASSWORD operands.
Interface overview
Command/Macro | Function |
CREATE-JV/CATJV | Create the job variable and specify protection attributes |
MODIFY-JV-ATTRIBUTES / CATJV | Change the protection attributes |
SHOW-JV-ATTRIBUTES / STAJV | Output the protection attributes |
Table 6: Commands and macros for specifying default protection attributes
The table presents an overview of the commands and macros used to specify the type of access (ACCESS), shareable (USER-ACCESS / SHARE), retention period (RETENTION-PERIOD / RETPD) and password protection (READ-PASSWORD and WRITE-
PASSWORD / RDPASS and WRPASS) default protection attributes.
Example
/create-jv jv=status,prot=*par(access=*write,user-access=*all-users, read-pass=c'rdpw',write-pass=c'wrpw')
The job variable status is created with the following properties:
Read and write access is permitted
All user IDs have access
A read protection password ('rdpw') is set
A write protection password ('wrpw') is set
Basic ACL protection
In a basic ACL (simple access control list) the read and write access privileges can be assigned explicitly for the user classes OWNER, GROUP and OTHERS.
This protection capability does not exist for temporary job variables.
When basic ACL protection is activated, the required access privilege must be set explicitly in order to obtain access. In contrast to the default access control (with ACCESS and USER-ACCESS) in a basic ACL, write access does not implicitly imply that the user has read privileges. Read access must be set explicitly to have read privileges.
The users are divided into the following user classes:
OWNER is the user ID of the owner or systems support.
GROUP is a collection of all user IDs that belong to the user group of the owner. In the basic function (without SECOS) these IDs are all other user IDs since only one user group exists. When the SECOS software product is used, several user groups can be defined using the SRPM function unit. Access by users that do not explicitly belong to a different group from the owner are still evaluated according to the access privileges of the GROUP group (the owner of a job variable can only belong to a maximum of one group). Access by the users that explicitly belong to a different user group are then evaluated according to the access privileges of the OTHERS group.
OTHERS are all user IDs that explicitly belong to a different user group from the owner or that do not belong to any user group. If SECOS is not used, the access privileges are to be assigned as for GROUP to avoid changes later on when SECOS is used.
The basic ACL protection attributes are only set when at least one access privilege was assigned explicitly (basic ACL is activated). The basic ACL protection attributes are shown in the OWNER, GROUP and OTHERS output fields using the SHOW-JV-ATTRIBUTES command. The values “R W (read and write), “R -” (read only), “- W” (write only) or “- -” (no access) are shown for each user class. The fields are only shown when basic ACL is activated.
The basic ACL protection can be activated, access privileges can be changed or the basic ACL protection can be deactivated with the CREATE-JV or MODIFY-JV-ATTRIBUTES command in the basic ACL operand by explicitly setting the access privileges.
A job variable is created without basic ACL by default.
When basic ACL is activated, access control is performed according to the access privileges settings. The shareable and type of access standard protection attributes are not evaluated in this case.
When SECOS is used, several user groups can exist. This means you can also assign different access privileges to the group of the owner and other user groups.
When the basic ACL protection is activated for an existing job variable, the user can create a basic ACL by specifying basic ACL=*PREVIOUS that matches the values of the default access control (see the command MODIFY-JV-ATTRIBUTES in the “Commands”
manual [1]). When a job variable is created, a basic ACL can be created by specifying basic ACL=*STD in which only the owner has all access privileges.
The macros and their operands used to specify the basic ACL protection are listed in the following interface overview together with the commands.
Interface overview
Command/Macro | Function |
CREATE-JV/CATJV | Create a job variable and specify protection attributes |
MODIFY-JV-ATTRIBUTES / CATJV | Change the protection attributes |
SHOW-JV-ATTRIBUTES / STAJV | Output the protection attributes |
ADD-USER-GROUP | Enter user group in the user catalog of a pubset and assign user IDs to a user group |
REMOVE-USER-GROUP | Delete the user group |
SHOW-USER-GROUP | Show the user group entry |
Table 7: Commands and macros for specifying access protection with basic ACL protection
Example
/create-jv jv=jv.develop——————————————————————————————————————————————— (1)
/add-user-group group-id=develop1,add-group-member=user1——————————————— (2)
/mod-jv-attr jv=jv.develop,protection=(basic-acl=(
owner=(read=*yes,write=*yes),
group=(read=*yes)
others=(read=*no)————————————————————————————————— (3)
(1) | A job variable “jv.develop” is created |
(2) | A group named “develop1” is created by the owner of the job variable “jv.develop” and his own user ID (USER1 here) is entered as a member of the group. |
(3) | Access protection is defined using a basic ACL for the job variable “jv.develop”. The owner of the job variable has read and write access to the job variable. The members of the group to which the owner of the job variable belongs (“develop1”) may only read the job variable. All other user IDs (“others”) may not access the job variable. |
GUARDS protection
Access control for job variables can be done using guards (Generally Usable Access ContRol ADministration System). This type of access protection only takes effect when the subsystem GUARDS is loaded (part of the SECOS software product, see [10]). There is no protection capability for temporary job variables.
Access to a job variable is controlled through a special access profile (guard) that contains all condition under which access is permitted or rejected (date, time, time period, user ID). Every access profile is created with the corresponding GUARDS commands and is stored as an entry in the Guards catalog under a name assigned by the user. Every pubset has a guard catalog that is managed separately from the user files.
Access to a job variable protected by a guard is only possible when the conditions specified in the guard entry permit it.
Activating guard protection
Guard protection is activated when a value not equal to *NONE is specified in the GUARDS operand for a CREATE-JV call.
If guards are not assigned for all access privileges, then the access privileges not specified are also entered in the file catalog as “not specified” (*NONE). The access control will reject a corresponding access because no privileges were specified. Write privilege does not implicitly imply read privileges for GUARDS.
The macros and operands used to specify the GUARDS protection are listed in the following interface overview together with the commands.
Interface overview
Command/Macro | Function |
CREATE-JV/CATJV |
|
MODIFY-JV-ATTRIBUTES / CATJV |
|
SHOW-JV-ATTRIBUTES / STAJV | Output the protection attributes |
CREATE-GUARD | Create a guard (does not contain any protection mechanism yet) |
DELETE-GUARD | Delete a guard |
ADD-ACCESS-CONDITIONS | Specify the access conditions of a guard |
MODIFY-ACCESS-CONDITIONS | Change the access conditions of a guard |
SHOW-ACCESS-CONDITIONS | Output the access conditions of a guard |
SHOW-ACCESS-ADMISSION | Output the access conditions of a guard that are valid for the caller's user ID. |
A job variable is linked to a guard entry by entering a guard name in the corresponding operand of the macro/command (CATJV/CREATE-JV, MODIFY-JV-ATTRIBUTES). The link is maintained in the catalog entry of the job variable.
Example
/create-guard guard-name=protjv———————————————————————————————————————— (1)
/create-jv guardjv,protection=(guards=(read=protjv,write=*none))——————— (2)
/add-access-conditions guard-name=protjv,
subjects=*user(user-identification=mueller),
admission=*parameters(time=*interval(from=07:00,
to=17:00))————— (3)
(1) | The guard “protjv” is created. |
(2) | The job variable “guardjv” is created and access protection via GUARDS is activated through the link to the guard “protjv”. Read protection is controlled through this guard, write access is not permitted. |
(3) | It is entered in the guard “protjv” that the user “mueller” may access the job variable “guardjv” between 7:00 and 17:00. (If the specified guard does not exist yet, then it is created automatically). |
The catalog entry for the guard protection can also be created without the GUARDS subsystem. However, there are no access privileges for the job variable in this case.
If guard protection is activated for a job variable, then all access types of the GUARD operand (READ and/or WRITE) that are not explicitly set are set to *NONE. Access via these access types is not possible then. For example, when /modify-jv-attributes jvtest,protection=(guards=(read=protjv)) is executed, protection=(guards=(read=protjv,write=*none)) is set automatically.
Only when a job variable protected by guards is accessed is the check to see if the specified guard entry (guard name) exists, if it can be used and if the user is permitted to access the job variable using the corresponding type of access based on this access profile.
Note
A job variable cannot be accessed when protection via guards is entered in the catalog entry for the job variable but there is still no access profile defined in the guard catalog for the specified guard name. The same is also true when the catalog entry for access protection via guards is created without the SECOS software product.
You must have access privileges to access the guards of another user ID. The access privileges for a guard are checked only when this guard is required for access control.
Deactivating guard protection
A guard entry is only deactivated by specifying the operand GUARDS=*NONE (in the CREATE-JV and MODIFY-JV-ATTRIBUTES commands). If the job variable does not have a basic ACL entry after that, then access protection for the job variable is only controlled by the default access control, the passwords and the retention period.