Scope of Authority for group-SPECIAL, group-AUDITOR, and group-OPERATIONS Users

The authority of the group-SPECIAL, group-AUDITOR, and group-OPERATIONS users is limited to the resources that are within the scope of the group. Resources that are within the scope of the group include the following (refer to Figure 1 and Figure 2):

Resources owned by the group (for example, GROUP1.DATA owned by GROUP1)
Resources owned by users who are owned by the group (for example, USER2.DATA owned by USER2 who is owned by GROUP1)
Resources owned by subgroups that are owned by the group (for example, GROUP2.DATA owned by GROUP2 that is owned by GROUP1)
Resources owned by subgroups that are owned by subgroups, owned by the group, and so on (for example, GROUPZ.DATA owned by GROUPZ that is owned by GROUP2 that is owned by GROUP1).

Note that the scope of the group does not extend to the following resources:

Resources owned by groups owned by users who are owned by the group (for example, GROUPY.DATA owned by GROUPY owned by USER2 who is owned by GROUP1)
Resources owned by users who are, in turn, owned by users who are owned by the group (for example, USER6.DATA owned by USER6 who is, in turn, owned by USER5 who is owned by GROUP2).

By establishing the group structure so that subgroups are owned by their superior groups, the authority of the group-SPECIAL, group-OPERATIONS, and group-AUDITOR user can be made to percolate down through the group tree structure as far as the security administrator desires. When a user's attribute percolates down from a group to which the user is connected with the group attribute, the user's authority in the subgroups is the same as if the user was connected directly to the subgroups with the group attribute.

Note: The data security monitor (DSMON) produces a group tree report that lists, for each requested group, all of its subgroups, all the subgroups' subgroups, and so on. This report can be very useful in checking to which subgroups the authority of the group-SPECIAL, group-OPERATIONS, or group-AUDITOR applies. For more information on the group tree report, see z/VM: RACF Security Server Auditor's Guide.

The limits of the security administrator, group administrator, auditor, and operations personnel authority at the group level are described in Table 1. (Of course, these users continue to have whatever authorities they possess from other sources, such as ownership, that are not covered by their group-level authorities.)

Table 1. Scope of Authority for User Attributes at the Group Level
Resource	Attribute, User, and Authority
Users	Group-SPECIAL attribute: A user with the group-SPECIAL attribute has full authority to work with: User profiles that are owned by the group User profiles that are owned by a subgroup owned by the group, by a subgroup owned by a subgroup that is owned by the group, and so on. The group-SPECIAL user must have the CLAUTH attribute in a class in order to give the CLAUTH attribute to another user in that class. The group-SPECIAL user cannot give a user the SPECIAL, AUDITOR, or OPERATIONS attribute at a system level, but can assign these attributes at the group level. To create new users, the group-SPECIAL user must have the CLAUTH attribute in the USER class. Group-AUDITOR attribute: A user with the group-AUDITOR attribute can perform all of the functions of an auditor, but is restricted to the same subset of users as the user with the group-SPECIAL attribute.
Groups	Group-SPECIAL attribute: A user with the group-SPECIAL attribute has authority over that group, over subgroups owned by that group, and so on. The group-SPECIAL user can connect any user to, or remove any user from, any group that is included in this authority.
SFS files and directories	Group-SPECIAL attribute: A user with the group-SPECIAL attribute has full authority to work with FILE and DIRECTRY profiles: Owned by the group Owned by users or groups that the group owns With a second qualifier that is a user identifier owned by the group. The group-SPECIAL user can also define FILE and DIRECTRY profiles with a second qualifier that is a user owned by the group. Group-AUDITOR and Group-OPERATIONS attributes: A user with the group-AUDITOR or group-OPERATIONS attribute can perform all of the functions of an auditor or operator, but is restricted to the same subset of SFS files and directories as the user with the group-SPECIAL attribute.
General resources	Group-SPECIAL attribute: A user with the group-SPECIAL attribute has full authority to work with: Resource profiles that are owned by that group Resource profiles belonging to users or groups that are owned by the group. To create new resources, the user must have the CLAUTH attribute in the applicable class. Group-AUDITOR and Group-OPERATIONS attributes: A user with the AUDITOR or OPERATIONS attribute can perform all of the functions of an auditor or operator, but is restricted to the same above subset of resources as the user with the group-SPECIAL attribute.

The following two figures show the scope of authority of a group-SPECIAL user. Figure 1 shows a typical authority structure containing three major groups: Group 1, Group 2, and Group 3.

Note: Although this figure uses z/OS® terminology to illustrate relationships between users and groups and their resources, the same concepts apply to relationships between users and groups and their resources on z/VM® systems.

Figure 2 shows the addition of a new element: a new user, USER1, is connected to Group 1. The resultant authority USER1 receives as a group-SPECIAL user is highlighted (the nonshaded area) in part 2 of this figure.

USER1 has authority to the profiles in the nonshaded area for the reasons listed in Table 1. USER1 does not have authority to any of the resources in the shaded area for the following reasons:

GROUP1 does not own IBMUSER, GROUP3, USER3, or USER4.
GROUP1 does not own GROUPY.
Neither GROUP1 nor GROUP2 own USER6.
USER3.DATA is not owned by a user who is owned by GROUP1.
USER4.DATA is not owned by a user who is owned by GROUP1. If USER4.DATA is a z/OS data set, USER1 cannot display the profile information for this data set with LISTDSD, even if USER2, for example, is in its access list. (However, by using IRRUT100, RACF® informs USER1 that USER2 is in the access list of USER4.DATA.)
U4A is not a general resource owned by a user who is owned by GROUP1.

Note: Although this figure uses z/OS terminology to illustrate relationships between users and groups and their resources, the same concepts apply to relationships between users and groups and their resources on z/VM systems.

The figure is explained in the text. — Figure 1. Group-Level Authority Structure