db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: [Grant/Revoke]Proposal for invoker/definer model
Date Tue, 14 Mar 2006 17:58:24 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
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
Mamta Satoor wrote:<br>
  <div>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. </div>
  <div><span class="gmail_quote">On 3/13/06, <b
 class="gmail_sendername">Daniel John Debrunner</b> &lt;<a
 href="mailto:djd@apache.org">djd@apache.org</a>&gt; wrote:</span>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left:
Satoor wrote:<br>
&gt; While going through some of the Derbylist mails on Grant/Revoke, I<br>
&gt; realized that various database objects in a sqlStandard mode may
&gt; switching authorizers from the invoker to different definers and
&gt; versa. This piece of task sounds interesting to me and hence I have<br>
&gt; following proposal for implementing it.<br>
[snip view example]
&gt; I am considering implementing above scenario of switching from one<br>
&gt; authorizer to another by keeping a stack of authorizers in<br>
&gt; GenericLanguageConnectionContext. Prior to intoduction of
&gt; mode for Grant/Revoke, Derby was written to run everything with
&gt; as the authorizer. This single invoker authorizer information is<br>
&gt; currently kept in GenericLanguageConnectionContext's<br>
&gt; authorizer(GenericAuthorizer) field. This field gets set to
&gt; authorizer when GenericLanguageConnectionContext gets initialized
at the<br>
&gt; database connect time. This happens in<br>
&gt; GenericLanguageConnectionContext.initilize method. In addition to<br>
&gt; initilizing authorizer, this method also sets the default schema
to a
&gt; schema with the same name as the invoker. So, as we can see,<br>
&gt; GenericLanguageConnectionContext currently just deals with one<br>
&gt; authorizer and that authorizer is always the authorizer
corresponding to
&gt; the user who has made connection to the database.<br>
&gt; But with the addition of Grant/Revoke to Derby, we can have
&gt; authorizers active during the execution of a single sql statement.
&gt; support multiple authorizers, GenericLanguageConnectionContext
will need<br>
&gt; to keep a stack of these authorizers and a corresponding stack of<br>
&gt; default schemas descriptors for those authorizers.<br>
How will this handle multiple open statements within a Connection, each<br>
with a different stack of authorization identifiers? Maybe with<br>
Satheesh's comment that this scheme wouldn't work for views makes this<br>
an irrelevant question. Though, while the language connection context
seems ideal when there was only a single authorization identifier, it<br>
doesn't quite seem right now, when statement execution drives the<br>
current authorization identifier.<br>
How similar or different is the requirement to the existing model for
pushing and popping SQL permission restrictions for routines (NO SQL,<br>
CONTAINS SQL etc.)? In that case the current sql permission level is<br>
maintained in the statement context, and not the language connection<br>
The statement context might match exception clean up better:<br>
&gt; In case the sql being executed runs into an exception, as part of
the cleanup work,<br>
&gt; we need to remove all the authorizers (except the first one on the
stack since<br>
&gt; it belongs to the "invoker" ie the user who has made this
connection to the database)<br>
I don't think is correct, consider any nested situation, for example<br>
routines with server-side JDBC logic, the exception can be caught in
routine and execution continued. The effective authorization identifer<br>
can not be revoked back to the initial connection, it needs to be reset<br>
to the correct level. For example if the routine was invoked by a<br>
trigger then the authorization identifier should revert to the definer<br>
of the trigger. Using the statement context might provide the correct<br>
behaviour here, as statement contexts are (hopefully :-) popped<br>
correctly in such a situation.

View raw message