Comparing DB2 and CA ACF2 Option for DB2 Features › Controlling Access to DB2 Resources › Privileges Associated with Plan or Package Creation and Execution

Privileges Associated with Plan or Package Creation and Execution

DB2 uses application plans or packages to communicate database requests to the database manager. A plan or package determines the path that DB2 takes to access the data, so you do not have to tell DB2 how to access it. Plans and packages separate what a program is permitted to do from who can use the program.

The BIND and REBIND subcommands create and change application plans and packages. Used with the OWNER option, the BIND or REBIND subcommand can name your primary ID or one of your secondary IDs as owner of the bound plan or package. Users with SYSADM, SYSCTRL, or system DBADM can specify any authorization ID as owner. An ID with BINDAGENT can make the grantor’s ID owner of the plan or package. Used without the OWNER option, the BIND subcommand gives your primary ID ownership. When you omit OWNER on the REBIND subcommand, the previous owner retains ownership.

The OWNER option lets you change owners of a plan or package. The former owner no longer owns the plan, however, he retains the privileges specific to ownership of the plan or package (such as BIND and EXECUTE for plans) with the WITH GRANT OPTION. Not even someone with SYSADM authority can revoke these privileges. To do this, you must drop the object and create it again with a new owner.

To create or bind a new plan or package, the owner must hold certain privileges such as BINDADD, SYSADM, SYSCTRL, or System DBADM. To bind a replacement plan or package, the binder must own the plan or package or possess certain privileges. For example, if you are replacing a package with a new owner, you must have the BINDAGENT privilege from the new owner, be the new owner, or have the SYSADM, SYSCTRL, or system DBADM authority. In addition, the new owner must have the appropriate BIND or BINDADD privilege, or SYSADM, SYSCTRL, or system DBADM authority as well as all of the necessary privileges to use the SQL statements in the program. Users of the plan or package do not need all of these privileges. They need only the EXECUTE privilege to use the plan. They do not require authorization for the tables accessed by the plan or package.

Corresponding CA ACF2 Option for DB2 Feature

CA ACF2 Option for DB2 treats an application plan or package as a resource that must be protected. When a plan or package is bound, CA ACF2 Option for DB2, like DB2, validates the authority of the owner to bind the plan or package and execute the embedded SQL statements. CA ACF2 Option for DB2 determines the owner by the OWNER option on the BIND or REBIND subcommand, or if OWNER is not specified on the BIND, by 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 requires that you issue GRANT statements to give privileges to the owner, CA ACF2 Option for DB2 requires that you write appropriate rule sets to grant these privileges to the owner determined at the bind. To execute a plan or package, users do not need the privileges required by the embedded SQL statements. Typically, users require only the EXECUTE privilege or ownership of the plan or package.

The $UIDOWNER or $LIDOWNER control statement in the rule set determines who has ownership privileges over the plan or package. For example, ownership privileges over a plan are BIND and EXECUTE. If you specify OWNER on the BIND or REBIND subcommand, CA ACF2 Option for DB2 ensures that the owner has the BIND or BINDADD privilege or is specified by the $UIDOWNER or $LIDOWNER control statement.

You can change who has ownership privileges over a plan or package at any time. Just change the rule set, then compile and store it. If you are using a global directory, you must also rebuild the directory using the F ACF2, REBUILD operator command. If you want to use the changed rule set to validate a previously bound plan or package, you must rebind the plan or package to make the new access restrictions effective. With CA ACF2 Option for DB2, the former owner does not retain any of the implicit privileges retained with native DB2 security.

Like DB2, CA ACF2 Option for DB2 uses the value of the owner determined by the bind to set the high‑level qualifier of unqualified objects referenced by the plan or package. With unqualified objects, the high‑level qualifier is appended to the front of the object’s name to determine the entire name. You can also use the QUALIFIER option to determine the object name.