[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561181#action_12561181
]
Daniel John Debrunner commented on DERBY-3327:
----------------------------------------------
One high level comment and some specific comments on the patch:
high-level
--------------
It seems somewhat strange that this is implemented as a stack of activations
and because of that we end up needing to store role information in two
different places, in the LCC if it's the top-level and the activation
otherwise. Since the activation represents an individual statement is its job
to hold SQL context information?
Looking closer at the SQL standard (4.34.1.1 and 4.27.3) I'm not sure the patch
is implementing exactly what is described there.
One portion is the SQL-session context, that comes into being with the routine
invocation. Then within the SQL-session context is an authorization stack.
The patch seems to be morphing the two into one, executing a routine creates
just a role stack.
DERBY-1331 is an outstanding issue to handle SET SCHEMA within routines
correctly, which I think falls into the SQL-session context logic, creating a
morphed stack here might make it harder to fix that.
Would it make more sense to have objects that followed the model described by
the SQL specification, even if currently they are not fully utilized?
Something like:
SQLSessionContext - pushed for a routine call, stack maintained in the lcc
has a field for schema (future for DERBY-1331)
has a field for authorization stack (stack of AuthorizationCell)
AuthorizationCell (see 4.34.1.1)
field for user identifier
field for role name
Maybe the existing StatementContext class is already fulfilling the purpose of
SQLSessionContext?????
specific patch comments
----------------------------------
For the field 'callers' in GenericLanguageConnectionContext.java I think it's
holding a stack of Activations. Could you state this in its javadoc.
(oh for Java 5 :-)
In the javadoc comment for 'callers' it says:
For the top level, the current role is kept here, cf. 'currentRole'.
Since this is the javadoc for callers, the here applies to callers, but I think
you really mean the current class. Would this be correct?
For the top level, the current role is kept in this.currentRole.
In BaseActivation can the comments for the field callActivation be javadoc
comments, so that IDE's will pick them up.
Can comments be added for nestedCurrentRole.
Even with the comments for BaseActivation.callActivation I became a little
confused. Looking elsewhere I can see that callActivation is the activation of
the enclosing CALL statement, that would have been useful in the javadoc. I'm
somewhat confused by the need for BaseActivation.callActivation and the stack
in the LCC. It seems that the stack of activations is being kept twice, once in
LCC and once through the activations.
I wonder about the cost of this stack maintenance, for SQL routines that are
defined as NO SQL it might be a significant overhead. E.g. SIN() function.
Avoiding the context manipulation for those routines could be a follow on, but
I'd be interested in the overhead with this change.
> SQL roles: Implement authorization stack
> ----------------------------------------
>
> Key: DERBY-3327
> URL: https://issues.apache.org/jira/browse/DERBY-3327
> Project: Derby
> Issue Type: New Feature
> Components: Security, SQL
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Fix For: 10.4.0.0
>
> Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
> DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat
>
>
> The current LanguageConnectionContext keeps the user authorization identifier
> for an SQL session.
> The lcc is shared context also for nested connections (opened from stored
> procedures).
> So far, for roles, the current role has been stored in the lcc also. However,
> SQL requires that
> authorization identifers be pushed on a "authorization stack" when calling a
> stored procedure, cf.
> SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
> This allows a caller to keep its current role after a call even if changed by
> the stored procedure.
> This issue will implement the current role name part ("cell") of the
> authorization stack.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
