Invalid and inoperative packages
In Db2, when a privilege that is required by a package is revoked, the package is invalidated. Db2 can automatically rebind an invalidated package if proper privileges are granted.
If the revoked privilege
is the EXECUTE privilege on a user-defined function, Db2 marks
the package inoperative, instead of invalid; you will need to manually rebind the inoperative
package.
If a privilege that the package depends on is revoked, and if you want to invalidate the package or make it inoperative, you must use the SQL GRANT statement to grant the revoked privilege and then use the SQL REVOKE statement to revoke it. If you remove any object privilege from a user that is used to bind a package, you also need to revoke the EXECUTE privilege that the user has on the associated package. This prevents the user from accessing the package.
If you use an authorization access control routine, the exit routine does not have the ability to tell Db2 that a privilege is revoked. In this case, Db2 does not know that it needs to invalidate the package.
If you set the AUTHEXIT_CACHEREFRESH subsystem parameter to ALL and when the user profile or resource access is changed in RACF®, Db2 refreshes the cache entries of the package authorization, the routine authorization, and the dynamic statement. Db2 also checks for static package dependency and invalidates the package when one of the following resource class permissions is removed from the user:
- INSERT, UPDATE, DELETE, SELECT on a table
- USAGE on a sequence
- EXECUTE on a stored procedure
- EXECUTE on an UDF (Dependent packages are marked inoperative.)
- READ, WRITE on a global variable.
If EXECUTE on a package is revoked from the user, Db2 will check for plan dependency and invalidates the plan.
A package can be invalidated only when Db2 is active during ENF notification and if the name of the affected RACF profile contains discrete characters. ENF notification ignores a profile if it is associated with the DSNADM class or if its name contains any generic characters (*, **, &, %). If the package owner is a user (not a RACF group) and if the user is associated with a group that had the required privileges when the package was bound, you need to explicitly permit the user all the privileges required for invalidating the package and then delete the permissions in RACF.