[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561747#action_12561747
]
Daniel John Debrunner commented on DERBY-3327:
----------------------------------------------
Just to be clear, I'm not recommending the StatementContext, just trying to
ensure that some understanding of it exists before another context is added.
The wrong approach would be to blindly add a new context just because
StatementContext is not understood. I think there is probably some overlap
between the StatementContext and a SQLSessionContext, but maybe
StatementContext does not quite match the role of SQLSessionContext, but then
what role is StatementContext implementing in the model defined by the SQL
standard? Discussion like this is good to get an understanding.
Maybe Activation is acting as the SQLSession context, as in your first patch?
I think in the last comment you raise an interesting point: For a procedure
that sets a role R and returns dynamic result sets, the role in force during
the processing of those dynamic result sets needs to be R, even though the
execute of the CALL returned (and thus R was popped from some stack).
> 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.
