RACF authorization checking reference

You can use the RACF access control module to perform RACF authorization checking for several Db2 objects.

This topic includes information about the RACF authorization checking through the RACF access control module for the following Db2 objects:

B: Buffer pools
C: Collections
D: Databases
E: User-defined distinct types
F: User-defined functions
G: Triggers
H: Global variables
J: Java™ archives (JARs)
K: Packages
L: Roles
M: Schemas
N: Trusted contexts
O: Stored procedures
P: Application plans
Q: Sequences
R: Tablespaces
S: Storage groups
T: Tables
U: Systems
V: Views

The sections that follow outline the series of authorization checks that occur in the RACF access control module to determine if the requesting user is authorized to use a particular Db2 privilege against a particular Db2 object type. If any authorization check in the series is successful, the privilege is granted. For examples of authorization processing in the RACF access control module, see Authorization processing examples.

In order to perform authorization checks, the RACF access control module uses the values passed with the following parameters to determine the Db2 object types and privileges:

XAPLTYPE: Db2 object type
XAPLPRIV: Db2 privilege
Restriction: The sections that follow show only the name of each Db2 privilege passed with the XAPLPRIV parameter. The RACF access control module uses a numeric XAPLPRIV value. See the Db2 macro DSNXAPRV in prefix.SDSNMACS to find the numeric value associated with each Db2 privilege name.

The profile name formats shown in this information are applicable if you are using multiple-subsystem scope (&CLASSOPT 2). If you are using single-subsystem scope (&CLASSOPT 1), the resource name does not include the Db2 subsystem name. If you are using Db2 data sharing, substitute Db2-group-attachment-name for Db2-subsystem in the profile name formats shown in this appendix.

Note: Having a database privilege on database DSNDB04 is the equivalent of having the privilege on any implicit database. After a privilege is granted, the authorization information is cached for faster re-checking. If the AUTHEXIT_CACHEREFRESH system parameter is specified and RACF commands are issued with generic character ** or * in the resource names, the entire authorization cache for the corresponding class being revoked might be refreshed. In this case, the performance of authorization checking might be impacted until the cache is successfully rebuilt.

Start of change When a privilege required by a package is revoked in RACF, the package is not automatically invalidated in Db2. If you want to invalidate the package or make it inoperative, you can use the SQL GRANT statement to grant the revoked privilege and then use the REVOKE statement to revoke it. Or, you can set the AUTHEXIT_CACHEREFRESH system parameter to ALL. See Invalid and inoperative packages and AUTH EXIT CACHE REFR (AUTHEXIT_CACHEREFRESH subsystem parameter) for more information. End of change