db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: How to invalidate when a role is revoked, so privileges will be rechecked?
Date Tue, 18 Dec 2007 16:14:02 GMT
Rick Hillegas <Richard.Hillegas@Sun.COM> 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

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

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).


View raw message