Securing Database Resources › SQL Security Enforcement › Runtime Security for Access Modules

Runtime Security for Access Modules

Overview

Each time a new copy of the access module is physically loaded by the runtime system, the privileges of the access module owner are checked.

The result of the security check performed on a new copy of an access module is the status of the access module. This information is cached in the PDE until a new copy is loaded (or until the system is recycled).

The status of the access module is one of the following:

• Not runnable—No one can execute the access module.
• Runnable—The owner holds all necessary privileges to execute the access module.
• Runnable/grantable—The owner holds all necessary privileges to execute the access module and to grant execution privilege on the access module to other users.

Runtime checking is required because a grantable privilege needed to pass execution privilege to users could be removed from the owner. Revocation of a privilege occurs independently of both CA IDMS and CA IDMS inter security.

A detailed description of runtime procedures for access module security follows.

On a Load of an Access Module

On a load of any access module, the CA IDMS program load function issues two security check requests to verify that the user has execution privilege for the access module. The first security check is for load privilege on the access module. An access module is just like any other load module. When loaded, you need to check to see if the user has the authority to load the program. The second security check is issued to see if the requestor has authority to access the database using the SQL statements that are stored in the access module.

• If the checks fail, an error is returned.
• If the checks succeed, normal load processing occurs.

If a new copy of the access module is being loaded and the security check on the user succeeds, CA IDMS program load processing:

1. Calls a database routine to scan the module and return this information about the access module:
   • Status (Not runnable, runnable, runnable/grantable).
   • Authorization ID of the owner.

   This information is cached.

2. The CA IDMS program load function requests a check to determine if the user is allowed to execute the access module based on its status:
   • If status is not runnable, then the check fails.
   • If status is runnable/grantable, then the check succeeds.
   • If status is runnable and the user (or a group to which the user belongs) is the owner of the access module, then the check succeeds; if status is runnable but the user is not the owner, the check fails.
3. Depending on the result of the preceding step, the program requesting the load receives a return code indicating one of these conditions:
   • Security violation—The user does not have execution privilege on the access module.
   • Runnable—The user has execution privilege on the access module.
   • Not grantable—The user cannot execute the access module because the owner does not hold all required privileges.

On a CREATE or ALTER ACCESS MODULE Command

The access module compiler issues a security check to determine whether the user has the CREATE or ALTER privilege on the access module. If not, an error is issued and no further processing is done.

If the security check succeeds, the access module compiler creates the access module. It then calls the database routine used by the CA IDMS program loader function to check the access module owner's privileges. The owner of the access module is the owner of the associated schema. The user who submits the CREATE or ALTER ACCESS MODULE statement is notified if the access module owner lacks any required privileges.

Note: The access module is stored whether or not the owner holds all required privileges. If you subsequently grant the owner any missing privileges, the access module will be runnable.

On Dynamic Compilation of an SQL Statement

There are three situations that require dynamic compilation of SQL statements:

• The statement is submitted through the Command Facility.
• A user-written program submits a dynamic SQL statement.
• CA IDMS determines that database changes require an access module to be recompiled.

In these situations, the access module compiler checks privileges as the statements are being compiled. The result of this checking is based on the same criteria used for a load:

• If status is not runnable, then the check fails.
• If status is runnable/grantable, then the check succeeds.
• If status is runnable and the user (or a group to which the user belongs) is the owner of the access module, then the check succeeds; if status is runnable but the user is not the owner, the check fails.