[EMAIL PROTECTED] wrote:
Daniel John Debrunner <[EMAIL PROTECTED]> writes:
The privilege checking should occur when creating the Activation which
is when the plan (shared) gets hooked up to the specific user's
java.sql.PreparedStatement. This is what happens today, but then
Activations are not re-used across re-executions of the same
java.sql.PreparedStatement.
Thus it's fine (should be :-) if multiple users are sharing the same plan.
I think for simple statements like SELECT * FROM T then the plan
should be dependent on T (which it will be) and the REVOKE
invalidation should be against T, not a privilege related to T. This
then indicates that the privilege set for that table has changed and
so any user must re-check its privileges. With the current code this
would invalidate the plan which I don't think is a problem since
REVOKE statements are not expected to be frequent. Ideally the revoke
would just mark current activations as needing to re-check privileges,
but I'm not sure if that complication is worth it for REVOKE.
I have created
https://issues.apache.org/jira/browse/DERBY-2594
to track this.
Thus maybe the bug is when a privilege is revoked an invalidation
against the object is was granted on is not being sent. I wonder if
there are existing bugs due to this, which would encourage fixing it
before changing the current correct privilege checking to something
"incorrect" only to revert it later.
I basically agree, but I'm worried that requiring DERBY-2594 to be fixed
before proceeding with DERBY-827, could mean that neither make it into
10.3. And I'll admit that it is a personal itch of mine to get
DERBY-827 in, if at all possible.
Yes, I see the concern & I'd like to see DERBY-827 in 10.3, but it just
seems wrong if the fix to DERBY-827 involves making things occur once
per execution when the point of the issue to to stop things occurring
per-execution. :-)
I'll help out on the invalidation as I can since I'm already looking in
that area for DERBY-2380.
Dan.
