db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: [Grant/Revoke]Proposal for invoker/definer model
Date Tue, 14 Mar 2006 05:02:02 GMT
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 <djd@apache.org> 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.
>
>

Mime
View raw message