db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <Dag.Wan...@Sun.COM>
Subject Rationale for REVOKE EXECUTE.. RESTRICT vs. REVOKE <role>
Date Wed, 16 Apr 2008 13:12:18 GMT


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

* 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?


View raw message