Although the Catalog Synchronization Utility fully supports most DB2 privileges and attributes, the following sections detail conditions that might require you to manually synchronize some of the DB2 privileges.
Ownership of resources is not synchronized because CA Top Secret Option for DB2 handles privileges associated with ownership differently from DB2. When a resource is created, DB2 grants the owner all privileges to the created resource. These privileges cannot be removed by a REVOKE command. In CA Top Secret Option for DB2, the creator of the resource does not automatically become the owner of the resource and does not obtain any implicit privileges for the created resource. The CA Top Secret Option for DB2 ADDTO command is used to define ownership of a resource by an ACID. This might cause CA Top Secret Option for DB2 and the DB2 catalog to be out of sync for the creator's privileges for this resource.
GRANTs for resources to owners in CA Top Secret Option for DB2 have the WITH GRANT OPTION clause added to the GRANT statement.
Database privileges have a hierarchical structure of their own. Administrative authorities of DBADM, DBCTRL, and DBMAINT all imply other database privileges. For example, DBADM authority implies that the user has all fifteen database privileges. If authorizations are created giving a user administrative authority and a database privilege within the scope of the database administrative authority, CA Top Secret Option for DB2 cannot discern that the user has been given the specific privilege because it is already implied by the higher level administrative authority. Therefore, when this situation occurs, only a grant for the higher level database authority is generated.
The Catalog Synchronization Utility does not support the following privileges:
Therefore, these privileges are not synchronized.
Remember that revoking a privilege from a user in DB2 can also revoke that privilege (or privileges granted due to that privilege, such as a SELECT granted because of a SYSADM privilege) from other users. Cascade revokes can occur during the synchronization process and can leave the DB2 catalog in an unsynchronized state with respect to CA Top Secret Option for DB2. This is because the Catalog Synchronization Utility uses standard GRANT and REVOKE statements to update the catalog. Just as when you used the authorization in the DB2 catalog for securing DB2, the potential for this problem is greatest when many different users grant the privileges in the catalog. The problem does not occur if the current install SYSADM granted the privileges or a special ID set up for granting privileges that has the same privileges in the DB2 catalog and in CA Top Secret Option for DB2 (such as the ID used by the Catalog Synchronization Utility) granted the privileges.
To resolve the problem, you can run a subsequent synchronization that includes the users and resources that were affected by the cascade revokes.
The purpose of the CA Top Secret Option for DB2 Catalog Synchronization Utility is to create GRANT and REVOKE statements that enable you to ensure the DB2 catalog is up‑to‑date. However, REVOKE statements can invalidate some of your plans. DB2 invalidates plans whenever a privilege used to create the plan is revoked and the user no longer holds the privilege from another source. Therefore, when the Catalog Synchronization Utility is run and REVOKE statements are issued against privileges used to create a plan (and the user does not hold the privilege from another source), any plan affected by the REVOKE is marked invalid by DB2 and must be rebound.
You can list those plans marked invalid in the catalog by performing the following sample SQL query. We suggest you run this query before and after you execute the Catalog Synchronization Utility to determine which plans you must rebind.
SELECT NAME, CREATOR
FROM SYSIBM.SYSPLAN
WHERE VALID = 'N'
ORDER BY NAME
To create a view, a user must have one or more DB2 privileges, such as SELECT or SYSADM. If you REVOKE the privilege that was used to create a view, that view is dropped unless:
By default, TSDB2SY2 does not generate revokes for the SYSADM, SYSCTRL, system DBADM, and DBADM administrative authorities. This is due to the number of catalog queries required to determine which, if any, views are dropped if the REVOKE statement is generated and executed. For example:
To instruct the Catalog Synchronization Utility to generate grants for administrative authorities that do not result in the dropping of a view(s), specify:
VIEW ACTION(REVOKEADMIN)
To generate REVOKEs for administrative authorities that do not result in the dropping of views, to generate a list of REVOKEs that are not generated because the REVOKE results in one or more views being dropped by DB2, and to list the views that are not dropped if the REVOKE is generated, specify:
VIEW ACTION(REVOKEADMIN,WARN)
To generate REVOKEs for all administrative authorities regardless of the impact on views, specify:
VIEW ACTION(REVOKEADMIN,DROP)
To generate REVOKEs for all administrative authorities and receive a list of the views that are affected, specify:
VIEW ACTION(REVOKEADMIN,WARN,DROP)
Another default is that TSDB2SY2 does not generate REVOKEs that cause views to be dropped. The VIEW ACTION(WARN) control statement causes the CADB2SGS report to list the revoked privilege and all views that are dropped if the REVOKE is generated and executed. If you specify the VIEW ACTION(DROP) or VIEW ACTION(WARN,DROP) control statement, the REVOKE is generated. When TSDB2SY3 processes the REVOKE, the views are dropped and must be rebuilt.
In native DB2 security, any privilege granted on database DSNDB06 is implicitly granted on database DSNDB01. No explicit privileges can be granted on database DSNDB01.
In contrast, in CA Top Secret Option for DB2, databases DSNDB01 and DSNDB06 are treated like all other databases and each will have its own DB2DBASE resource authorization. This means that grant statements are generated for both DSNDB01 and DSNDB06 databases. However, since native DB2 does not accept grants for DSNDB01, these grants will fail with a ‑204 SQLCODE. The Catalog Synchronization Utility will issue a warning message for this failure and continue processing. To avoid this situation, you can suppress generation of grant statements for DSNDB01 by specifying an EXCLUDE DBS(DSNDB01) control statement for the TSDB2SY2 job. If you need to compare access authorizations for DSNDB01 and DSNDB06, we recommend that you run a separate synchronization that includes these two databases and all users. You can then analyze the TSDB2SY2 reports or the generated GRANT statements to compare the accesses defined for the DSNDB01 and DSNDB06 databases.
SYSOPR is the default user ID used by DB2 when processing DB2 operator commands from the console. This ID must have the SYSOPR system privilege in the DB2 catalog. Therefore, the Catalog Synchronization Utility will never revoke the SYSOPR system privilege from SYSOPR.
However, when a situation does occur for a REVOKE of SYSOPR from SYSOPR, the Catalog Synchronization Utility issues an informational message and suppresses the generation of the REVOKE. Examples of this would be:
The Catalog Synchronization Utility does not differentiate between a standard privilege and a privilege that has the WITH GRANT option. They are treated the same for synchronization purposes.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|