In DB2, privileges are also derived from ownership of a resource. Owners of a resource have full privileges on the resource, which cannot be revoked, and can pass the privileges to other users. These privileges depend on the type of resource. For example, ownership of a view enables you to drop the view. Ownership of a table lets you:
See the IBM DATABASE 2 System and Database Administration Guide for complete information about the privileges of ownership.
In general, ownership is determined when an object is created and is influenced by:
Except for application plans, packages, and collections, you create DB2 objects through SQL CREATE statements in which you give the object a name. To create application plans or packages use the SQL BIND or REBIND statements. Collections are implicitly created when a package is bound with a new collection name.
Dynamic and static SQL can influence ownership of an object. In general, if you use dynamic SQL to create an object, the owner is the value of the current SQL ID. The current SQL ID identifies what ID you are associated with. If you use static SQL, you can specify the owner when you bind the plan or package. If you do not specify an owner, the binder’s primary ID becomes the owner. Unless you specify the QUALIFIER option, the owner’s ID becomes the high‑level qualifier of the unqualified objects created and must possess all of the privileges needed to create the objects.
As mentioned above, the value of the register, SET CURRENT SQLID, influences ownership. Through the exits or the SET CURRENT SQLID statement, you can set your current SQL ID to your primary ID or one of your secondary IDs. An ID with SYSADM authority can set the SQL ID to any ID. The SQL ID is used for implicit name qualifiers, implicit ownership assignment, and GRANT and REVOKE authorization checking. It enables you to use the privileges of a secondary ID and to set ownership based on its value. Of course, you must have authority to use the ID that you specify.
For example, if you create an object with an unqualified name (that is, you do not specify a high‑level index) using dynamic SQL, your current SQL ID becomes the owner. Your current SQL ID can be one of your secondary IDs or your primary ID. If you create an object with an unqualified name using static SQL, the owner of the plan or package created by the bind operation becomes the owner of the object, unless the QUALIFIER option was specified on the BIND statement. Creating objects with qualified names becomes even more complicated. See the IBM DATABASE 2 System and Database Administration Guide for more information about determining ownership.
Your privileges also help determine ownership. If you have the DBCTRL authority, you can name any qualifier as owner of a table or index. If a user grants you BINDAGENT you can specify that user as owner of the plan or package. If you have the SYSADM, SYSCTRL, or system DBADM authority, you can name any qualifier as owner of a view.
You cannot change ownership of a resource (other than ownership of a plan or package) in DB2. To change ownership, you must drop the object and create it again with a new owner. This means that, among other things, the following is true:
In CA ACF2 Option for DB2, ownership of resources is determined by CA ACF2 Option for DB2 rules, not by the creator of the object. Although an CA ACF2 Option for DB2 rule might allow any user to create an object (unlike DB2), it does not automatically grant him ownership privileges. Under CA ACF2 Option for DB2, users can create objects even though the high‑level qualifiers do not match their primary IDs or one of their secondary authorization IDs, even if they do not have the DBCTRL, SYSADM, SYSCTRL, or system DBADM authority. However, users who create objects and users who match the high‑level qualifiers of objects have no ownership privileges over the object. Through CA ACF2 Option for DB2 rules, you specify what kinds of access users can perform (such as CREATETAB) and which users are owners.
With CA ACF2 Option for DB2, you specify the owner or owners in the $LIDOWNER or $UIDOWNER control statement of the CA ACF2 Option for DB2 rule set. The $LIDOWNER control statement contains the logonid of one resource owner. The $UIDOWNER control statement contains a UID mask to specify a group of resource owners. For example, specify ***DEVPGR to represent all users who have DEVPGR in the fourth through ninth positions of their UIDs. All of these users (for example, all development programmers) are granted ownership privileges over the resource. (For differences in the way plan and package owners are treated, see the “Privileges Associated with Plan or Package Creation and Execution” section.)
Another difference is that resource ownership in CA ACF2 Option for DB2 does not automatically grant users the right to administer security. This means that resource owners do not necessarily have the right to change CA ACF2 Option for DB2 rule sets and, therefore, grant users privileges. With DB2, owners can automatically grant privileges to another user using the WITH GRANT OPTION clause. (For more information about this, see “Delegating Authority,”) In CA ACF2 Option for DB2, only security administrators (users with SECURITY specified in their logonid records) and users specified by the %CHANGE or %RCHANGE control statement can administer CA ACF2 Option for DB2 rules. CA ACF2 Option for DB2 owners, however, have the same implicit privileges to access a resource that DB2 owners have. If you want CA ACF2 Option for DB2 owners to be able to also administer security, specify their UIDs in the %CHANGE or %RCHANGE control statement.
In CA ACF2 Option for DB2, the owner of a resource is straightforward and easily changed. If you are authorized, you can change the owner of a resource at any time without affecting any other object. To change the owner, change the $UIDOWNER or $LIDOWNER value, compile the rule, and store it in the Infostorage database.
Certain resources do not have owners. For these resources, you do not specify an owner. These resources are system privileges, utilities, and buffer pools.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|