Owner-controlled logging

Owners of resources can specify, in the resource profile, what types of accesses to log (successes, failures, or both) and what level of access to log (READ, UPDATE, CONTROL, or ALTER). Owners can also specify that no logging is to occur for an access that is a success or failure. Owner-controlled logging is not directly under your control, but you should verify that resource owners request a level of logging that is consistent with the sensitivity of the resource. Furthermore, your installation can use three methods to override the logging that an owner specifies in the resource profile.

1. First, you can suppress auditing for all resources in a specific class by specifying LOGOPTIONS(NEVER(class-name)) on the SETROPTS command. Likewise, you can activate auditing for all access attempts for all resources in a specific class by specifying LOGOPTIONS(ALWAYS(class-name)). See Activating auditing for access attempts by class.
2. Second, if you have the AUDITOR attribute, you can specify additional logging that supersedes the owner's logging specification for a specific resource by adding audit controls to the resource profile. Note that you cannot change the owner's logging specifications for a specific resource profile, only add to them. You can do this for specific resource profiles by specifying the GLOBALAUDIT operand on the ALTDSD or RALTER command. The use of these controls is described in Data set controls and General resource controls.
3. Third, for resources that have their authority checked by RACROUTE REQUEST=AUTH, your installation can bypass a profile owner's logging specification by using the RACROUTE REQUEST=AUTH postprocessing exit routine. This exit routine can, for certain accesses, specify unconditional logging or unconditionally suppress logging. For example,
   • An installation might use the exit routine to specify unconditional logging for accesses to a highly classified resource.
   • An installation might suppress logging when the exit routine recognizes READ access to common system resources, such as SYS1.MACLIB.
   You should be aware of any such exit-routine specifications. For more information about using exit routines, see z/OS Security Server RACF System Programmer's Guide.