You will have to rebind the world.
Db2 uses the contents of the SYS%AUTH tables to determine
when a permission is revoked. Package invalidation in this case. It
does not evaluate if
there are other, alternative, permissions that would bypass the
need to invalidate.
This is why item 3 (below) failed. The revoke (from public) did not
trigger a re-evaluation of
the package owner's authorities.
Don't count on item 4 always working. I have seen situations
(albeit several versions ago)
where DB2 (as it was) prefered a grant to public over anything else
- even install sysadm.
After rebinding the world, check SYSTABAUTH to confirm that PUBLIC
is no longer the
GRANTOR of any row on the tables.
If you have a view that is dependant on a grant, it will be dropped
when the grant is revoked.
On 19 Sep 2018 at 19:19, Vickers, Mark wrote:
> Hi Folks,
> We need to replace I,U,D authorizations which were granted to
PUBLIC with a non TSO
> We only have RACF validating the TSO user logon, from there it
is all DB2 internal
> This is what we tested:
> 1. Revoked I,U,D from
public on one table and tested an online screen and package got
> -904 (invalidated)
> 2. Tried rebinding the
package which did not work until we gave I,U,D on the table to
> package owner.
> 3. Then started over back
from 1. With the PUBLIC access back on, granted I,U,D to the
> package owner, revoked from public and the package still got
> 4. We figured out if we do
the grant to package owner, then rebind, then revoke from
> public, there was no outage, all worked.
> Am I missing some other authority (like BINDAUTH on the PLAN
or maybe CREATE
> on the COLLID) or is there a better way to do this without
rebinding the world ?
This email has been checked for viruses by AVG.