[EMAIL PROTECTED] wrote:
Mamta Satoor <[EMAIL PROTECTED]> writes:
One thing that comes to my mind with privilege checking only at first
execution is will it be a problem if different users execute the same
statement? Will we be able to know that even if the statement has already
been executed once, we should do the privilege checking because this time,
it is a different user who is executing the statement.
Uhhh, dunno :) A valid question for which I don't have an answer. Hmm,
Knut's suggestion about factoring this out in separate jira is looking
more and more appealing. Especially if it could wait until after
10.3 when we all would have more free cycles (I hope).
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.
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.
It's possible for views/triggers that they would need to depend on a
specific privilege, rather than just the table, because of the rules of
dropping such items when the privilege is revoked. Thus the invalidation
based upon the privilege may still be needed.
Dan.
