When Authorization Checking Takes Place and Why
When a user requests access to a RACF-protected resource (such
as a minidisk), the resource manager issues a RACROUTE REQUEST=AUTH
request (or the RACHECK macro1). Based
on the specifications on the RACROUTE REQUEST=AUTH request, or RACF® authorization request, RACF determines whether the requesting
user is authorized to access the resource.
- If the user is authorized to the resource, then RACF returns a
successful
return code to the resource manager. The resource manager then allows the request to complete. - If the user is not authorized to the resource, then RACF returns an
unauthorized
return code to the resource manager. The resource manager then fails the request.RACF issues a message indicating that the resource is not protected.
- If the resource is not protected (for example, if no profile exists
for it), then RACF returns
the default return code for the class. For general resource classes,
the default return code is the
not protected
return code, unless otherwise specified in the class descriptor table entry for the class.If the
not protected
return code is issued, the resource manager then either fails or allows the request. Most resource managers allow the request.RACF issues a message indicating that the resource is not protected.
Note:
- SMF log records and/or messages may be generated, depending on the options in effect and whether RACF granted or denied access to the resource.
- For spool data (protected by the VMRDR class), if the user ID of the requesting user is the user ID that created the spool file, RACF grants the request.
- For z/VM® events that are not controlled—on a system-wide basis or for particular users—RACF is not called for authorization.