[
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 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.
