Previous Topic: Securing Access to Non-SQL-Defined DatabasesNext Topic: Schema and Subschema Security


Securing Run Units

About Run Units

The primary access to data stored in non-SQL-defined databases is through a subschema using navigational DML. This type of database transaction is a run unit.

A run unit is started by a BIND RUN-UNIT command, which effectively opens a logical view of the database as defined by the subschema. Within the subschema, privacy locks and LRF path logic restrict the operations which can be performed on the data accessible through the subschema.

When you secure run units, you control who can access a non-SQL-defined database through navigational DML. Until you secure run units, any user can access a non-SQL-defined database through navigational DML.

About the Run Unit Resource

At bind time, the following elements are available for security checking purposes:

The combination of these three elements—database-name.subschema-name.program-name—identify the run unit resource on which authority is checked when access to a non-SQL-defined database using navigational DML is requested.

How to Secure Run Units

You secure run units by securing the DB resource.

Note: For more information, see Securing Databases.

If you secure run units externally, you must also include an entry in the SRTT with external security information for resource type NRU.

How to Grant Execution Privilege on a Run Unit

Run units must be categorized before you can grant execution privilege on them. For example, this statement assigns run units for a group of programs that access the PRODSCHM database to the Category EMPINFO:

create resource
  Category empinfo

Note: For more information, see CREATE RESOURCE.

To allow a user to execute a run unit, you issue a GRANT EXECUTE statement on the Category that contains the run unit. For example, this statement gives privilege on the EMPINFO Category to two groups of users:

grant execute on
  Category empinfo
  to hr_mgrs, corp_execs;

Note: For more information, see GRANT Execution Privilege.

Runtime Run Unit Checking

If the security option for DB is internal, BIND processing requests a check of privilege on the Category to which the run unit is assigned. The internal security system uses dynamic table support to maintain a sorted cache of run units and their associated Category.

If the security option for DB is external, the check request is routed to external security with the class and resource name information specified on the SRTT entry for NRU.