z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Resolving conflicts among grouping profiles

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

A resource name can appear in more than one resource group and can also have a profile of its own. If a resource is protected by more than one profile, RACF® resolves any conflicts by merging the information from the individual profiles. Merging occurs during RACLIST processing according to the default rules shown in Table 1 and occurs only under one of the following conditions:
  • A member name is defined as a member of more than one grouping-class profile.
  • A member name is defined as both a profile in the member class and a member of a grouping-class profile.

Guideline: Do not specify the same member name in more than one grouping-class profile. Because of the way in which profiles are merged, it might become difficult to determine exactly what protection any one resource has.

Grouping-class profiles are processed in the order that the SEARCH or RLIST command would show them. Member-class profiles, which are processed after all grouping profiles are processed, are also processed in the order that the SEARCH or RLIST command would show them.

If you want to change the order in which profiles are processed or you do not want to use the default rules for merging the information from multiple profiles, you can use the REQUEST=LIST exit routines to change them. For details about RACLIST processing and the REQUEST=LIST exit routines, see z/OS Security Server RACF System Programmer's Guide and z/OS Security Server RACROUTE Macro Reference.

Table 1. Rules for merging conflicting profiles
Merging rule Example
The most restrictive UACC is used. If one profile has a UACC of NONE and another has a UACC of UPDATE, the UACC of NONE is selected.
For any particular user, the least restrictive of any duplicate access list entry is used. For user STEVEH, if one profile has an access list entry of STEVEH(NONE) and another has an access list entry of STEVEH(UPDATE), the access list entry of STEVEH(UPDATE) is selected.
Auditing is done if requested by any of the duplicate profiles. All AUDIT and GLOBALAUDIT values are processed. If one profile requests auditing and another does not, auditing is selected. If one profile requests logging of all failures and the other profile requests logging of all successes, both successes and failures are logged.
The values of the most recent profile are used for the following profile values: APPLDATA, DATA, NOTIFY, and OWNER. If the first profile specifies NONOTIFY and another profile specifies to notify USER1, no user is notified.
The highest level is used. If one profile specifies LEVEL(99) and another specifies LEVEL(00), the value used for level is 99.
All unique security categories are processed. If one profile has a category of ACCTG and another profile has a category of PAYROLL, both the ACCTG and PAYROLL categories are selected.
The lowest security level is used. If one profile has a security level of CONFIDENTIAL and another has the lower security level of ROUTINE, the security level of ROUTINE is selected.
The security label of the working profile is used. By default, this is the security label of the first profile found. RACF chooses the security label of the first profile it encounters during RACLIST processing and ignores the security labels for subsequent profiles that must be merged. Therefore, the value of the "merged" security label depends on the order in which the profiles are processed.
The terminal timezone of the working profile is used. By default, this is the TIMEZONE value of the first profile found. RACF chooses the timezone value of the first profile it encounters during RACLIST processing and ignores the timezone values for subsequent profiles that must be merged.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014