[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561507#action_12561507
]
Dag H. Wanvik commented on DERBY-3327:
--------------------------------------
Thanks for the information, it is very useful!
When you suggest the StatementContext may be sufficient to hold the SQL session
context, I presume you mean the StatementContext of the calling statement? It
has (about) the same lifetime as the procedure invocation - but see question
below. So the activation and/or statementContext of, say, a nested "VALUES
CURRENT_USER" would reference the parent (CALL) statement context to get at the
nested SQL session context? If you meant the statement context of the "VALUES
CURRENT_USER", it has to get its session state from somewhere? (As I understand
it, the lifetime of the statement context is limited to prepare and/or
execution of a single statement.)
What about the following case: I think the activations of dynamic result sets
may need the dynamic context after the procedure has returned, say, if the
statement yielding the result set references CURRENT_ROLE and that this is
evaluated lazily only when the cursor is accessed (rs.next()). The statement
context for the CALL has been popped (and reset) at that time (from
GEnericPreparedStatement#execute), right? Would it be ok with the current model
for it to stay live until the dynamic result set us closed? If not, perhaps a
separate SQLConnectionContext (which could stay around longer) is better?
Also, since the lcc.getStatementContext returns the current top context, it
would not yield the right one if invoked by a dynamic result set of an
activation after procedure return, I think?
Sorry if I am misconstruing reality here; trying to understand more ;)
> 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.
