When you create an application plan or package from static SQL statements embedded in a program, you are binding the plan or package. You can specify the owner of a plan or package when you bind or rebind it. During the bind, DB2 checks whether you are authorized to specify the ID as owner. The ID must be your primary ID, one of your secondary IDs, or an ID that granted you the BINDAGENT privilege. If you have SYSADM, system DBADM, or SYSCTRL authority, you can specify any ID as owner. If you do not specify an owner, the default owner is your primary authorization ID. In addition, DB2 checks whether the owner can perform the bind and has all of the privileges required by embedded SQL statements in the plan or package. For example, to rebind a plan, you must have one of these:
To complete the bind, the new owner must have one of these:
You can also specify when the owner must have all the privileges required to create an application plan or package—at bind time or at execution time. During bind processing with VALIDATE(BIND) specified, the bind operation is unsuccessful when the owner does not have the privileges required by each SQL statement contained in the plan or package. If you specify VALIDATE(RUN) for the bind operation, the owner does not have to possess all of the required privileges at bind time. Instead, at bind time, DB2 still checks the plan or package owner’s privileges for those required by each SQL statement, but it also checks the owner’s privileges again at execution for those authorities that the owner did not hold at bind time.
Other users who want to use the plan or the package require only the EXECUTE privilege on it. No other privileges or authorities are necessary. DB2 uses the value of the SET CURRENT SQLID register to authorize use of the plan or package. A user then exercises some of the owner’s privileges when he executes the plan or package. If the owner changes or some of the owner’s privileges are revoked, the plan or package is invalidated. It must be rebound and the new owner must be granted the required privileges.
CA ACF2 Option for DB2 validates a plan or package the same as native DB2. CA ACF2 Option for DB2 uses the authority of the owner to bind the package or plan and to execute the embedded SQL statements. CA ACF2 Option for DB2 determines the owner by the OWNER option on the BIND or REBIND subcommand. If OWNER is not specified on the BIND, CA ACF2 Option for DB2 uses the binder’s primary ID. If OWNER is not specified on the REBIND, CA ACF2 Option for DB2 uses the current plan owner as the owner, just as DB2 does.
CA ACF2 Option for DB2 uses the value of the current SQL ID to determine if the user has execute authority over the plan or package. With this current SQL ID, CA ACF2 Option for DB2 uses the plan or package rule set, the collection rule set for packages, or the SYSADM rule set to determine if the user has the EXECUTE privilege over the plan or package.
If you change a plan owner’s authority in a rule after the plan is bound, the plan continues to be valid. For plans bound with VALIDATE(BIND), users can continue to execute the plan even though the plan’s owner no longer retains the needed authority. For plans bound with VALIDATE(RUN), CA ACF2 Option for DB2 validates all SQL requests not validated during the bind using the owner’s current authorities. For those SQL requests that passed the bind, the owner’s previous authorities are still in effect. This means that, if you want the current authorities for all SQL requests to be effective, you must rebind a plan after an owner’s authority changes to ensure that you reflect the access restrictions defined by the changed CA ACF2 Option for DB2 rules.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|