Dynamic Checking
When a user executes a tool which allows SQL statements to be entered explicitly (or implicitly as a result of information provided on a form), security checking is performed as each statement is processed. This is also true if a user-written program issues dynamic SQL statements.
The authorization ID against which the privileges are checked is the authorization ID of the executing user, except in certain instances associated with view access, as discussed in Securing Views. Every privilege required to execute a given SQL statement is checked. The results of the check are cached for the life of the database transaction, to avoid repetitive authorization checks for similar access to the same table-like object.
Securing the Dynamic SQL Statement cache
If dynamic SQL statement caching is in effect, users and administrators should keep in mind that the SQL cache contains images of the source of dynamic SQL statements. These images can possibly contain confidential information. The source of the cached SQL statements is accessible through the table procedure SYSCA.DSCCACHE and any view (that is SYSCA.DSCCACHEV delivered during installation), that projects the STATEMENT column of this table procedure. It is recommended to secure access to the SYSCA.DSCCAHE table procedure and any view exposing the column STATEMENT of SYSCA.DSCCACHE.
External Security
If security on the database being accessed is controlled externally, the security checks are issued by CA IDMS as it executes the commands and the authorization permissions are cached for the life of the transaction or task whichever ends first.
CA IDMS Internal Security
If security on the database being accessed is controlled by CA IDMS internal security, security checks are issued by the access module compiler (AMC) as it compiles the dynamic SQL command.
|
Copyright © 2014 CA.
All rights reserved.
|
|