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. For details about users with group-level attributes
and their scope of authority related to resources, users and resources,
see Table 1, Figure 1,
and Figure 2.
Resources, not users or other groups, that are within the scope
of the group include the following.
- Resources owned by the group (for example, GROUP1.DATA owned by
GROUP1)
- Resources that are owned by users who are owned by the group (for
example, USER2.DATA owned by USER2 who is owned by GROUP1)
- Resources that are owned by subgroups that are owned by the group
(for example, GROUP2.DATA owned by GROUP2, which is owned by GROUP1)
- Resources that are owned by subgroups that are owned by subgroups,
owned by the group, and so on (for example, GROUPZ.DATA owned by GROUPZ,
which is owned by GROUP2, which in turn is owned by GROUP1).
Note that the scope of the group does
not extend to the
following resources:
- Resources that are owned by groups that are owned by users who
are owned by the group (for example, GROUPY.DATA owned by GROUPY which
is 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 of 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/OS Security Server RACF 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 |
|---|
| Data sets |
- Group-SPECIAL attribute:
- A user with the group-SPECIAL attribute has full authority to
work with:
- Data set profiles that are owned by the group
- Data set profiles that have a high-level qualifier that is the
same as the group identifier
- Data set profiles that are owned by users or groups that are owned
by the group
- Data set profiles that have a high-level qualifier that is a user
or group identifier owned by the group
The group-SPECIAL user can also define data set profiles with
a high-level qualifier that is the group identifier or a user or group
identifier 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 limited
to the same subset of data sets as the user with the group-SPECIAL
attribute.
|
| General resources |
- Group-SPECIAL attribute:
- A user who has 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 who has the AUDITOR or OPERATIONS attribute can perform
all of the functions of an auditor or operator, but is limited to
the same above subset of resources as the user with the group-SPECIAL
attribute.
|
| 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 that is owned by the
group, by a subgroup that is 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 who has the group-AUDITOR attribute can perform all of
the functions of an auditor, but is limited to the same subset of
users as the user with the group-SPECIAL attribute.
|
| Groups |
- Group-SPECIAL attribute:
- A user who has 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.
|
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: Groups 1, 2, and 3.
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 non-shaded
area) in part 2 of this figure.
USER1 has authority to the profiles in the non-shaded area for
the reasons summarized 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. USER1
cannot display the profile information for this data set with LISTDSD,
even if USER2, for example, is in its access list. (However, if USER1
runs the IRRUT100 utility, RACF® informs
USER1 that USER2 is in the access list of USER4.DATA.)
- U4A is not a general resource that is owned by a user who is owned
by GROUP1.
Figure 1. Group-level authority
structure
Figure 2. Scope of authority
for a group-SPECIAL user
z/OS Security Server RACF Security Administrator's Guide
Copyright IBM Corporation 1990, 2014