db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2594) Revoking a privilege from an SQL Object should invalidate statements dependent on that object
Date Fri, 27 Apr 2007 06:53:15 GMT

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

Dyre Tjeldvoll commented on DERBY-2594:

It is quite possible that a new action isn't required. I wasn't
sure so I played it safe.

I didn't mean to say that GrantRevokeConstantAction should call
invalidateFor directly (although it certainly could seem
so). Currently the stack looks like this:

GrantRevokeConstantAction -> XPrivilegeInfo -> invalidateFor(XPermsDescriptor, ACTION)

So we should add 

GrantRevokeConstantAction -> XPrivilegeInfo -> invalidateFor(XDescriptor, INTERNAL_COMPILE_REQUEST)


This will work for tables, but I haven't checked for
RoutinePermsDescriptor and RoutineDescriptor. That is, I haven't
verified that all statements that depend on a Routine actually
are Dependents of the RoutineDescr.

> Revoking a privilege from an SQL Object should invalidate statements dependent on that
> ---------------------------------------------------------------------------------------------
>                 Key: DERBY-2594
>                 URL: https://issues.apache.org/jira/browse/DERBY-2594
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            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.

View raw message