Rick Hillegas <[EMAIL PROTECTED]> writes: > Thanks, Dag. This is helping me understand the problem. I'm still > unclear on the following point. Here's the setup: > > a) User U sets her session S to operate under role R > b) The DBO revokes role R from U > c) Now U does more work in session S > > But what is the role associated with session S now? Is it still R? If > so I would expect that the problematic statement would still be able > to execute in session S until the role of session S is changed.
The way I read the standard, the revoke is effective immediately. In my current implementation, a session's current role is still (technically) set although no longer valid (see the field GenericLanguageConnectionContext#currentRole, which is a role descriptor) However, it is lazily (re)set to none as soon as the session tries to "use" it after it has been revoked. So, if you try to reprepare the same statement after the revoke, the authorization would fail, as it should. The issue here is that the statement has already been prepared at a time at which the role was not yet revoked, so the activation for the prepared statement thinks it is still valid. A reprepare, for example provoked by my alternative c) approach, causes all connections to regenerate the result set structure and as a part of that one-time set-up, also do the authorization check, and hence assure that the needed permission is available, or fail the execute. This is a bit heavy-handed, though, since connections not affected by the role revoke will be forced to do extra work, hence my alternative b) to invalidate just the affected activations. This does away with the reprepare, but would just make the affected connections reinitialize the activation (including redoing the authorization check). Dag
