Since they are contained in libraries, members enjoy the same degree of protection as the libraries themselves. It is also possible to give members added protection by making access rights explicit, instead of implicit.
Member access rights
r : w : x : h : a : | read write execute hold administer |
The rights r, w, x and h are set for individual members and modified by means of the LMS statement MODIFY-ELEMENT-PROTECTION (see "MODIFY-ELEMENT-PROTECTION"). To display existing authorization settings, use the SHOW-ELEMENT-ATTRIBUTES statement (see "SHOW-ELEMENT-ATTRIBUTES").
Administer authorization is set for all the members in a given library with the LMS statement MODIFY-LIBRARY-ATTRIBUTES (see "MODIFY-LIBRARY-ATTRIBUTES") and for all the members of a given type with the statement MODIFY-TYPE-ATTRIBUTES (see "MODIFY-TYPE-ATTRIBUTES"). To display existing administer authorization settings, use the statement SHOW-LIBRARY-ATTRIBUTES (see "SHOW-LIBRARY-ATTRIBUTES") or SHOW-TYPE-ATTRIBUTES (see "SHOW-TYPE-ATTRIBUTES").
Administer authorization is used to specify the person(s) authorized to create, delete and rename members within a library or type.
The default setting for administer authorization is NONE, which allows all administration functions that are allowed by the protection of the library file.
Protection attributes can be modified only by the owner of the library.
For each right, one of the following protective mechanisms can be set:
NONE: | No special protection |
STD: | Standard protection (BACL) |
BY-GUARD: | Protection through GUARDS |
Password protection is linked to BACL protection and so plays no role in GUARD protection.
Only one mechanism can be active for a given right at any point in time, but different mechanisms can be set for different rights. If the mechanism set for a right is changed, the values of the previously active mechanism are lost.
If it is unclear on the basis of the active mechanism and the current system environment whether an access right exists, no access is permitted.
This may occur for the following reasons:
protection by GUARDS, but the GUARDS subsystem is not installed
Possible remedies are:
change the system environment
change the active protection mechanism (option available to library owners only)
The various mechanisms implement protection as follows:
NONE - no special protection
- no access check
STD - standard protection by BACL
Each of the access rights listed above is assigned by means of protection bits and possibly by means of passwords to the following groups of users:
OWNER:
Owners of the library file
GROUP:
Group of the owner of the library file
OTHERS:
All others
The group of selected users can be restricted further by means of passwords. Passwords are stored in encrypted form in the library. Access to a member protected by a password is permitted only if the password entered matches the password stored earlier in the password table (using the BS2000 command ADD-PASSWORD).
The groups of authorized users and the passwords are defined by means of the USER and PASSWORD operands, respectively, in the LMS statement MODIFY-ELEMENT-PROTECTION.
BY-GUARD - protection by GUARDS
Access is determined on the basis of a protection description stored in a guard.
A guard is an independent object of BS2000, which can be created, modified and deleted using BS2000 commands. The owner of the guard defines both the protection description and the group of users who may use the guard:
SCOPE = USERID / USER-GROUP / HOST-SYSTEM(see [6 (Related publications)])
The protection description contains conditions which must be satisfied before access is granted.
These conditions may include:
Date
Time
Weekday
Task privilege
Program loadedAccess is granted only if the library owner is (still) permitted to use the guard and the conditions specified in GUARDS have been satisfied.
The guard which is to be used to check access requests is specified by the library owner.
Only GUARD names which were accepted by the GUARDS subsystem may be used. No check is made to determine whether or not the specified guard even exists. Permissible GUARD names are stored in the library exactly as they were specified.
All GUARD names refer to the catalog ID (CATID) under which the library containing the GUARD name is cataloged.
GUARD names without USERID refer to the user ID (USERID) under which the library containing the GUARD name is cataloged.
GUARD names are displayed to everyone who is permitted to read the contents of the library.
When using GUARDS protection for libraries and members, it is necessary to bear in mind certain special aspects, for example that it makes sense to protect individual members of a library only if the library itself is also protected, i.e. is in “PROTECTED MODE”.
Example
The library LIBR, which contains the member MEMB1, is available under the user ID USER1. USER2 would like to access MEMB1. USER1 has the guard GUARD1, which allows access to USER1 and USER2. There are three cases to consider:
Only the library LIBR is read-protected by GUARD1
In this case, LIBR is not handled as if it were a file. It is recognized that LIBR is a library, and the access protection is different than it would be if LIBR were a normal file. The library is in PROTECTED MODE, so that access is possible only via LMS or via the COPY-FILE command. A further attempt by USER1 or USER2 to gain read access (e.g. SHOW-FILE LIBR) will be rejected. It is possible, however, to access individual members, for example with SHOW-FILE *L(LIBR,MEMB1,S).If one or more members of LIBR are protected with GUARDS, copying is no longer possible (see 3 below).
Only the members are protected by GUARD1.
This method of protection makes no sense because the library must then have USER-ACC=*ALL-USERS in order for USER2 to be able to see the library. In this case, USER2 can copy the entire library and so gain access to all its members, regardless of what protection is specified for the individual members.
The library and its individual members are protected by GUARDS.
This method provides protection for the individual members of a library. All the users who are to be allowed access to members must be granted corresponding access rights to the library. In this case, however, this means only that those users can see the catalog entry and access it with LMS.
Even then it makes sense to protect individual members with GUARDS. The actual access rights are determined by the lesser of the two access rights, i.e. if a user has no write access to the entire library, he cannot write a member even if a guard at member level would allow him to do so.
If libraries are protected with GUARDS but no further protection is defined for the individual members, users can work with the members in almost the same way as with files.
Initial member protection
The owner of the library file can define initial member protection for the library and/or a specific member type.
If initial member protection was defined, the protection is entered for new members. If no initial member protection was defined, members are created without additional protection and are protected only by the library file protection.
If initial member protection is defined both for the library and for the relevant member type, only the protection defined for the type is taken into account. If the initial member protection is changed, the change affects only the protection of members created after that time, i.e. the protection of existing members remains unchanged.
Overview of protection attributes
| ||||||||||||||||||||||||||||||||||||||||||||
Overview of rights required for LMS actions
The following overview shows which rights are required in order to perform specific LMS actions, and what conditions must have been satisfied. It is assumed that the library file can be opened in a suitable way.
The abbreviations used in the overview have the following meanings:
- | Action is either not permitted or not possible |
* | Action may be executed by anyone |
, | AND operator |
/ | OR operator |
EATTR = | (CCSN, USER-DATE/TIME) |
STATE | Member state set with MODIFY-ELEMENT-ATTRIBUTES. |
WRITE- | Value of WRITE-CONTROL in effect in the member scope (see |
a: | The caller must have administer authorization for the member scope.
|
r: | The caller must have read authorization for the member. |
w: | The caller must have write authorization for the member. |
x: | The caller must have execute authorization for the member. |
h: | The caller must have hold authorization for the member. |
E: | The caller must be the owner of the library. |
H: | The caller must be entered as the HOLDER of the member. |
B: | Explicitly or implicitly specified base version. |
LMS action | Required conditions | |||
WRITE-CONTROL= | DEACTIVATED | ACTIVATED | ||
Modify LIBRARY-ATTR | E | E | ||
Modify TYPE-ATTR | E | E | ||
Create 1st version | a | a | ||
Create nth version | a | H(B) 1 | ||
STATE= | FREE | IN-HOLD | FREE | IN-HOLD |
Show ELEMENT-ATTR | * | * | * | * |
Delete version | a,w | - | a,w | - |
Rename version2 | a,w | - | - | - |
Overwrite version | w | w,H | - | w,H |
Modify EATTR | a/w | - | a/w | - |
Set STATE=IN-HOLD | h | - | h | - |
Set STATE=FREE | h | H/E | h | H/E |
Read version | r | r | r | r |
Execute version | x | x | x | x |
Modify ELEMENT-PROT | E | E | E | E |
1The new version is created with the attributes of the base version, i.e. with STATE=*IN-HOLD.
2If a member is to be renamed with the name of another existing member, that member must be authorized to overwrite.
Notes
In systems without a group structure, no access is possible through the user circle “group”. A setting analogous to USER-ACCESS is, however, possible through the user circles “owner” and “all others”.
Member protection is meaningful only when the library file is protected against UPAM accesses. Library files are protected against UPAM accesses if they are protected by means of a Basic Access Control List (BACL) or GUARDS and have been properly set up.
Libraries input by a file transfer operation (openFT) are not considered to have been properly installed until they have been accessed for writing by PLAM.
For libraries that are protected against UPAM accesses, the following restrictions apply:
they can no longer be included in a library by ADD-ELEMENT
they can no longer be processed via remote file access (RFA).
For such applications, the BACL protection must be deactivated for the library file. The library file is then no longer protected against UPAM accesses. It can now be processed like any other PAM file.
Libraries which contain protection attributes and are protected against UPAM access can only be copied by their owner using COPY-FILE.
GUARD protection is possible, provided, of course, that the GUARDS subsystem is available.