[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561741#action_12561741
]
Dag H. Wanvik commented on DERBY-3327:
--------------------------------------
Thanks for helping me understand this better!.
So, I can trust the correct statement context to be available at
execution time. But it still seems not to be sufficient? The
statement context is initialized when pushed on the basis of read-only
information from EmbedStatement (which is a JDBC level object if I am
not mistaken again ;) whenever we are preparing/executing/using the
result set of a statement, but it does not have the lifetime of the
procedure so it can't hold the mutable state of current user, role and
schema?
Those would have to be stored in a data structure that would persist
throughout the lifetime of the procedure, I think. First I looked the
statement context of the caller. But using the debugger I see that the
statement context of the call of not pushed back when the a next() is
performed outside the caller on the returned dynamic result set, so
even the statement context of the caller seems to have too short a
lifetime to hold the dynamic state of the nested scope.
So unless I am still missing something here, I will try to work
towards a new context object to hold the nested SQL session state.
> 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.
