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 17:57:29 GMT
Dyre.Tjeldvoll@Sun.COM wrote:
> Daniel John Debrunner <djd@apache.org> 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.


View raw message