You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org> on 2007/04/26 19:45:15 UTC

[jira] Commented: (DERBY-2594) Revoking a privilege from an SQL Object should invalidate statements dependent on that object

    [ https://issues.apache.org/jira/browse/DERBY-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492073 ] 

Dyre Tjeldvoll commented on DERBY-2594:
---------------------------------------

My experimental change fails because a TableDescriptor can have
other Dependents besides GenericPreparedStatements. All possible
Dependents of TableDescriptor must be able to handle the action
being passed to them (the default is to trow an
exception). Passing on REVOKE_PRIVILEGE doesn't work because
that will cause views that depend on the TableDescriptor to be
dropped, and we will subsequently get a 'No such Table/View'
error.

I have now modified the experimental code to send a new
action (REVOKE_RECOMILE) to the TableDescriptor whenever the
TablePrivilegeInfo object sends a REVOKE_PRIVILEGE to the
TablePermsDescriptor. I have also extended ViewDescriptor and
SPSDescriptor and GenericPreparedStatement to handle the
REVOKE_RECOMILE action.

With this hack I get lang.GrantRevokeDDLTest (The old
lang/grantRevokeDDL2.sql test that first revealed this problem
has been moved to JUnit) to pass with re-use of result sets and
without checking authorization on every execute.

But I fear that this is the easy part. The real work is probably to: 

- Ensure that all SQL Objects for which a revoke will invalidate
  statements, actually have those statements as Dependents.

- That GrantRevokeCA actually calls DM.invalidateFor() on all
  relevant Providers (SQL object descriptors)

(Currently GrantRevokeCA can either refer to a
TablePrivilegeInfo, or a RoutinePrivilegeInfo. TablePrivilegeInfo
calls invalidateFor(TablePermsDescriptor, REVOKE_PRIVILEGE) and
RoutinePrivilegeInfo calls invalidateFor(RoutinePermsDescriptor,
REVOKE_PRIVILEGE_RESTRICT))

> Revoking a privilege from an SQL Object should invalidate statements dependent on that object
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2594
>                 URL: https://issues.apache.org/jira/browse/DERBY-2594
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.2.1.6
>            Reporter: Dyre Tjeldvoll
>         Assigned To: Dyre Tjeldvoll
>
> Revoking a privilege on a table will currently cause the DependencyManager.invalidateFor() to be called on the table's TablePermsDescriptor with the action=REVOKE_PRIVILEGE. However, the prepared statements that refer to that table are dependents of the table's TableDescriptor, but NOT its TablePermsDescriptor, so the statements are not invalidated after revoke.
> This problem is currently hidden by the fact that authorization is checked on every execution, but this will change when language result sets are no longer reused (see DERBY-827). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.