db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Question about grant/revoke
Date Thu, 26 Apr 2007 03:41:42 GMT
Dyre.Tjeldvoll@Sun.COM wrote:
> Mamta Satoor <msatoor@gmail.com> 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 

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.


View raw message