db-derby-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561772#action_12561772
] 

Dag H. Wanvik commented on DERBY-3327:
--------------------------------------

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

Yes, thats how I understand it also, it just needs access to the top element
somehow, but does not need to see a 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.

Thanks, I will investigate this.


> 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