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. Fww. I have assigned myself to DERBY-2594 and I will try to get it ready for 10.3, but since I'm going to JavaOne I don't have that much time before the proposed deadline. > 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. -- dt
