When a user executes an application plan or package he uses the privileges of the plan or package owner to access an object. Plan and package owners must possess the necessary privileges before they can create a plan or package. The SQL statements in the program determine the privileges needed. DB2 checks the owner’s privileges for authorization at bind time or execution time.
For another ID to execute the plan or package, it must possess the EXECUTE privilege on the plan or package. No other privileges are needed. In this way, an ID with the EXECUTE privilege (or DATAACCESS or SYSADM authority) can exercise the owner’s privileges within the restrictions imposed by the program.
DB2 determines ownership of a plan or package when the plan or package is created. Binding is a process that creates the application plan or package. During the bind, a user can give his primary ID ownership of the newly created plan or package. He can also specify any of his secondary IDs as owner. If the user is granted the BINDAGENT privilege from another user, the user can specify the grantor’s ID as owner. A user with SYSADM authority can specify any authorization ID as owner. A user can also specify any authorization ID as owner if he possesses the SYSCTRL or system DBADM authority.
DB2 lets you change ownership of a plan or package without dropping an object. Although the former owner no longer owns the plan or package, he retains some privileges on the plan or package after you rebind it. Not even someone with SYSADM authority can revoke these privileges. The only way to change the implicit privileges of an owner is to drop the object.
This chapter provided the basics of DB2 security. It explained DB2 resources, authorization IDs, and privileges and authorities. The next chapter describes the components of CA ACF2 Option for DB2. These components include the logonid, user identification string (UID), infostorage records, and administration.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|