db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [Grant/Revoke]Proposal for invoker/definer model
Date Tue, 14 Mar 2006 02:09:28 GMT
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.


Mime
View raw message