Dag H. Wanvik wrote:
Hi,
A while back I asked if anyone knew the rationale for requiring
RESTRICT on the revoke statement when an execute privilege is revoked,
but I got no reply so I am trying again :)
Similaryly, who do we not allow RESTRICT for table/column privilege?
Knowing the answer might help inform a decision I have to make when
specifying REVOKE <role> as part of the roles work.
Short background:
* Derby requires the RESTRICT semantics when revoking execution privileges.
Derby does not allow RESTRICT semantics when revoking table/column privileges.
That is, the revoke semantics for the two kinds of privileges are
incompatible.
* All kinds of privileges can be granted to a role, say role A. A
user who is granted the use of role A, can then make use of
privileges granted to A, both execution and table privileges,
possibly relying on the for creating persistent objects
(constraints, trigger or views).
* If role A is now revoked from the user, should we use RESTRICT or
CASCADE semantics? Since the role may enjoy both kinds of privileges
at the same time, no matter which semantics we choose it would
potentially be surprising given that Derby has imcompatible revoke
semantics as described.
If we let REVOKE <role>role have RESTRICT semantics, we would get RESTRICT
semantics for table/column privileges, if such a privilege had been
granted to A.
Conversely, if we let REVOKE <role> have CASCADE semantics, it could
surprise users if an execute privilege were had been granted to A.
If I have to choose, I would say that RESTRICT seems less risky in
that any surprise is less potentially damaging. What do you think?
Dag
Hi Dag,
I agree that RESTRICT seems less damaging. But it would be good to know
why RESTRICT was not allowed for table/column privileges. Maybe Mamta or
Dan could you shed some light on this.
Thanks,
-Rick
