Dynamic SQL statements are created and executed only when a program runs. These statements contain information that can be furnished only at execution time. They are created automatically when you request an action through, for example, SPUFI (SQL Processor Using File Input), which is a TSO facility that enables you to execute SQL statements without embedding them in an application program. As a result, DB2 checks the user making the request (the one executing the SQL statements) against the catalog tables. This user must have this privilege granted to his authorization ID. This authorization ID is the value of the SET CURRENT SQLID register. This value can be his primary ID or one of his secondary IDs. If he has SYSADM authority, he can set the current SQL ID to any authorization ID. The catalog must state that the ID is authorized to perform the requested function on the resource for DB2 to allow the action.
Dynamic SQL programs are complex to code. Under native DB2 security, they can also increase the amount of I/O to the catalog tables and thus increase performance overhead.
CA ACF2 Option for DB2 also checks dynamic SQL statements when they are executed. Instead of checking the catalog tables, CA ACF2 Option for DB2 validates the access attempt against the rules. If the user is not the owner of the resource, CA ACF2 Option for DB2 finds the rule entry that matches the environment of the requested action. With this rule entry and input from the DB2 OPTS infostorage record, CA ACF2 Option for DB2 determines whether the action should be allowed to continue or denied.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|