Co-owner protection

Co-owner protection allows the owners of objects to specify which of their objects they want to designate for co-owner protection and what conditions the co-owners must fulfil in order to perform administrative access.

The owner of an object is the user ID under which the object was or is to be created.

A co-owner is a user ID which is different from the object’s owner user ID but which possesses the same rights as the owner in respect of the object.

In general, the following applies to co-owners:

All read, write and execute access to files are controlled in accordance with the rules associated with the traditional file protection mechanisms:

• If a file or job variable is protected by means of SHARE/ACCESS or BACL, a co-owner has the same read, write and execute rights as the owner.

• If a file or job variable is protected by guards, access is controlled through the evaluation of access conditions which are contained in STDAC guards.

If a co-owner creates a file or job variable under a different user ID and then protects the file by means of an STDAC guard, then he or she must ensure, prior to file access, that his/her user ID is authorized to access the file. Similarly, file owners should be aware that co-owners can deny them data access.

However, both file owners and co-owners can use the /MODIFY-FILE-ATTRIBUTES command to recover their unrestricted right of access at any time.

The objects which can be co-owned are files and job variables.

Co-owners are linked by rules to the names of the objects that they are permitted to co-administer. Wildcards can be used to define a set of objects.

The rules are stored in rule containers (guards of the type DEFAULTP) that apply across sessions. As a user, you can create an unlimited number of such rule containers under your user ID. If the name of a rule container complies with the name convention (e.g. SYS.UCF), it is considered to be active and is used to check co-owner accesses (to determine, for example, when the command /CREATE-FILE FILE-NAME=$FOREIGN.FILE is executed that there is no discrepancy between the specified user ID and the user ID of the command originator). There is more information on this in "section Activating a rule container".

Co-ownership of TSOS

By default, the user ID TSOS has unrestricted co-administration rights for files and job variables throughout the system. However, SECOS permits these rights to be restricted. Consequently:

• A user under the user ID TSOS can only not change a specified set of attributes of an object owned by someone else if the object owner explicitly prohibits this by means of co-owner protection.

• This new function does not change the situation for nonprivileged users. They can only change attributes of a file or job variable owned by someone else if the object owner explicitly permits this by means of co-owner protection.

The ability to restrict TSOS co-administration rights brings the following benefits:

• The user under the user ID TSOS can be prevented from gaining unauthorized access to data by changing the protection attributes of files or job variables owned by someone else.

• Sabotage – the deletion of objects, for example – can be prevented.

You will find more information on this subject in section "Restriction of TSOS co-ownership".