[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561751#action_12561751
]
Daniel John Debrunner commented on DERBY-3327:
----------------------------------------------
I see the point about dynamic result sets was already noted in the functional
spec.
Looking closely at SET ROLE I see it doesn't require a authorization stack
(within a SQLSessionContext) because it only modifies the current role, it
never pushes a new cell onto the authorization stack.
So I'm coming to thinking that the initial patch is basically correct, with the
exception that there is no need to have a stack of activations or to link an
activation to its caller. It seems to me the current stacking of
StatementContexts has the required information already, upon execution the role
of the activation needs to be taken from the role of the activation of
currently executing statement (the most recently pushed StatementContext) or
the lcc if there is no currently statement being executed.
> 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.
