[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561754#action_12561754
]
Dag H. Wanvik commented on DERBY-3327:
--------------------------------------
> 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.
I absolutely agree, I am happy to get your feedback on this, Dan!
I will try to find out where Statement context fits in by reading up
a bit in the standard.
> 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).
I don't really grasp fully the design rationales involved in the
existing code here, I readily admit that. I used the activation of the
caller because it seems to have the correct lifetime to handle also
the dynamic result case (making R available after the call has
returned).
What I don't like about that solution is that the asymmetry (lcc for
outer, caller activation for inner scopes); it would be nice to have a
SQLSessionContext uniformly available somehow from both the root
connection scope and inside the procedures...
> 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.
