Dyre, I don't remember now if we discussed the 2 possible implementation choices ie to invalidate prepared statements by making them depend on privileges needed vs just catch privilege revocation at prepared statement execute time. I wonder if there is anything in the Derby dev list archive about this.
It seems like though that privilege revocation does get caught at execute time with the current implementation. Does that approach not work in some circumstances and is that why we are disucssing that approach? Mamta On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Mamta Satoor <[EMAIL PROTECTED]> writes: > Dyre, before I can understand the entire email, I need understanding this > part of your mail > "Assume I have a table T and a view V that references it, and that I > currently have select privilege on T." Who owns the table T when you say I > have a table T? Also, let me take the case where you are not the owner of > table T and you have been granted select privilege on T, then you don't > automatically get select privilege on view V. In that case, this statement > doesn't sound right "I currently have select privilege on T. Assume that I > have created a prepared statement P that selects from V." If you have select > privileges on T only, then you should not be able to preapre a statement > which selects from V. So, it will be good to know the exact ownership of the > objects and the exact privileges granted to the user who is trying to > prepare a statement. Thanks for precious time from your collation work to answer my question :) (If anyone else knows the answer to these questions it would probably be good if they could help Mamta out :) OK, I think I have confused things a bit. Forget the view (don't think it is relevant), and assume that P references T directly. Assume that some other user X created T and has granted me select privilege on T. I prepare P without problems and execute it. Then user X revokes my select privilege on T. I then try to execute P again. My understanding (based on Dan's comments earlier in this thread and in DERBY-827) is that P then should already have been marked as invalid by the revoke and that my attempt to execute P should trigger a re-compile, which in turn should fail because I no longer have select privilege on T. (This isn't what happens today btw. Currently P will not be invalid, but it checks that it has the necessary permissions on every execute, so the second execute of P will still fail) -- dt
