Defining Groups

This chapter provides in-depth information on defining groups for z/VM® systems.

Note: See Controlling OpenExtensions and BFS Security for information about RACF® security at the Portable Operating System Interface (POSIX) 1003.1 level.

The group structure of RACF can be mapped into the organizational structure that exists at your installation. That is, RACF conforms naturally to a tree structure of groups, with each group except the highest (the IBM-supplied SYS1 group) having a superior, or owning, group. Groups can correspond directly to business entities such as divisions, departments, and projects; users can be connected to one or more groups.

When you define a group, you should consider the basic purpose of the group. That is, is it an administrative group, a holding group, a functional group, or a user group?

When setting up RACF groups, you might want to keep in mind that the maximum number of users that you can connect to any one group is approximately 5900. See z/VM: RACF Security Server System Programmer's Guide for information about how to determine the exact maximum number.

Administrative Group: You can create a group simply as an administrative convenience. For example, you might create a group to represent an organizational entity, such as a region or a division.

With RACF delegation, you could create this kind of group for each group administrator. Operating from such groups, the group administrators could then define other groups needed by their local users.

Holding Group: A popular technique that retains user definition centrally, yet allows effective use of group administrators, is to establish a holding group. You define all users centrally and initially connect them to a group named HOLD with the minimum of authorities. HOLD does not appear in any access lists, and therefore is of no real significance to the user.

Group administrators, to whom you then give CONNECT (but not JOIN) authority, connect the appropriate users to the groups under their control and change the users' default group name as appropriate. This technique allows the installation to assign correct account numbers and control other installation considerations while allowing flexibility in the grouping of the user population.

Note: A group cannot contain more than approximately 5900 users. Therefore, if you have more than this number of users, you cannot assign them to a single holding group. Also, you should be aware that extremely large groups can have performance implications for the RACF database. For more information, see z/VM: RACF Security Server System Programmer's Guide.

Functional Group: A group can represent a functional area of the installation for the purpose of data sharing. For example, a financial analyst might need to access a variety of resources across many groups, such as accounting, payroll, marketing, and others. Of course, the owners of each resource could permit the financial analyst to access their resources by placing the analyst's user ID on an access list. But if a new financial analyst takes over the job, it is then necessary to add the new user ID to each RACF profile. Likewise, the RACF profiles will have to be updated when the analyst no longer has a need to access the data. This arrangement involves a great deal of unnecessary activity by the resource owners.

Instead, you can create a group that represents the financial analyst function and permits access to the data defined to the group. Access to the entire range of data can then be managed by controlling the user population in the defined group. For those cases involving one-time access, owners of the needed data would simply PERMIT access by the defined group. Where appropriate, the group name could be included in profile access lists to ensure automatic availability of needed data to the financial analyst group. New financial analysts could be connected to the group, as required, to gain access to the entire range of data. Likewise, analysts could be removed from the group whenever necessary. By controlling the user population of such a functional group, resource profile changes on a day-to-day basis become unnecessary.

User Group: You can define a group to serve as an anchor point for users who otherwise have no common access requirements. For example, engineers and scientists, as well as other problem-solving users, might have no need to access application-related data in the system. Their only interest might be in their own personal data. You can place this set of users in a single group that has no access to other data.

Also, you can define groups based on access level. For example, if PAY.195 is a VM minidisk, two groups could be defined, PAYREAD and PAYUPDTE, both of which would appear in the PAY.195 access list, but with READ and UPDATE access, respectively. Any users requiring access would be connected, as appropriate, by the group administrator.