Jacky Bright wrote:
Hi ..
few clarifications
1)
After Revoking DBADM authority from user, is it necessary to bind all
plans
and packages associated with that user ?
In our system in SYSTABAUTH there are few entries related to
packages(grantees) for which AUTHHOWGOT field is D and grantor is user
having dbadm authority.
In case I remove DBADM authority from GRANTOR, will that affect
operations
of applications even if Grantor has execute prvilege on all packages.
2)
when we say SET CURRENT SQLID = 'XYZ' while exeucuting any query what is
mean by this ..
Understandably If user ABC is part of group XYZ and database rights are
assigned to XYZ then while executing any query thru ABC user we have
to give
current SQL ID as XYZ.
JAcky
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
1) If the SQL in the package/plan was allowed to be bound by virtue of
the binder having DBADM on the data bases for tables referenced in the
package/plan, then removing DBADM will cause the package/plan to be
marked invalid. An automatic rebind will be attempted the next time the
package/plan is accessed. The automatic rebind will succeed if all the
necessary privileges are present for the package/plan owner; otherwise
the automatic rebind will fail. Having the execute privilege on a
package allows a prospective plan binder to name the package in the
PKLIST parameter of BIND PLAN.
A risk-avoiding alternative is to bind the packages/plans under a new
owner before revoking the DBADM authority.
A hindsight-based alternative is to BIND with an owner that's a group,
not an individual. Removing the individual from the group leaves
plans/packages with the group as owner unaffected.
2) SET CURRENT SQLID to a group affects subsequent dynamic DDL and DCL
statements; privileges needed for the statement are derived from the
CURRENT SQLID only. Dynamic DML SQL statements
(INSERT/UPDATE/DELETE/SELECT) are normally authorized by the aggregate
of privileges for a user and all of his/her groups. You need not set the
CURRENT SQLID to avail yourself of this privilege aggregation. Setting
the CURRENT SQLID also affects what is used for the owner for
unqualified SQL (unless you also use SET SCHEMA).
Hunter Cobb
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
