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.
