Thanks for working on this... I will provide a write up on how Derby
could implement view definer authorization model when sqlAuthorization
is on. I think views need a bind time solution to capture authorization
checks.
Satheesh
Mamta Satoor wrote:
Thanks, Dan and Satheesh, for your comments. I can see why
having the authorizer information at LanguageConnectionContext won't
work. I will look into putting this information in StatementContext,
similar to what is done for SQL permissions for routines.
thanks,
Mamta
On 3/13/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Mamta
Satoor wrote:
> While going through some of the Derbylist mails on Grant/Revoke, I
> realized that various database objects in a sqlStandard mode may
require
> switching authorizers from the invoker to different definers and
vice
> versa. This piece of task sounds interesting to me and hence I have
> following proposal for implementing it.
[snip view example]
>
> I am considering implementing above scenario of switching from one
> authorizer to another by keeping a stack of authorizers in
> GenericLanguageConnectionContext. Prior to intoduction of
sqlStandard
> mode for Grant/Revoke, Derby was written to run everything with
invoker
> as the authorizer. This single invoker authorizer information is
> currently kept in GenericLanguageConnectionContext's
> authorizer(GenericAuthorizer) field. This field gets set to
invoker's
> authorizer when GenericLanguageConnectionContext gets initialized
at the
> database connect time. This happens in
> GenericLanguageConnectionContext.initilize method. In addition to
> initilizing authorizer, this method also sets the default schema
to a
> schema with the same name as the invoker. So, as we can see,
> GenericLanguageConnectionContext currently just deals with one
> authorizer and that authorizer is always the authorizer
corresponding to
> the user who has made connection to the database.
>
> But with the addition of Grant/Revoke to Derby, we can have
different
> authorizers active during the execution of a single sql statement.
To
> support multiple authorizers, GenericLanguageConnectionContext
will need
> to keep a stack of these authorizers and a corresponding stack of
> default schemas descriptors for those authorizers.
How will this handle multiple open statements within a Connection, each
with a different stack of authorization identifiers? Maybe with
Satheesh's comment that this scheme wouldn't work for views makes this
an irrelevant question. Though, while the language connection context
seems ideal when there was only a single authorization identifier, it
doesn't quite seem right now, when statement execution drives the
current authorization identifier.
How similar or different is the requirement to the existing model for
pushing and popping SQL permission restrictions for routines (NO SQL,
CONTAINS SQL etc.)? In that case the current sql permission level is
maintained in the statement context, and not the language connection
context.
The statement context might match exception clean up better:
> In case the sql being executed runs into an exception, as part of
the cleanup work,
> we need to remove all the authorizers (except the first one on the
stack since
> it belongs to the "invoker" ie the user who has made this
connection to the database)
I don't think is correct, consider any nested situation, for example
routines with server-side JDBC logic, the exception can be caught in
the
routine and execution continued. The effective authorization identifer
can not be revoked back to the initial connection, it needs to be reset
to the correct level. For example if the routine was invoked by a
trigger then the authorization identifier should revert to the definer
of the trigger. Using the statement context might provide the correct
behaviour here, as statement contexts are (hopefully :-) popped
correctly in such a situation.
Thanks,
Dan.
|
