db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack
Date Wed, 23 Jan 2008 17:50:34 GMT

    [ 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.


Mime
View raw message