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 Tue, 22 Jan 2008 23:02:40 GMT

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

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

Thanks for the information, it is very useful!

When you suggest the StatementContext may be sufficient to hold the SQL session context, I
presume you mean the StatementContext of the calling statement? It has (about) the same lifetime
as the procedure invocation - but see question below. So the activation and/or statementContext
of, say, a nested "VALUES CURRENT_USER" would reference the parent (CALL) statement context
to get at the nested SQL session context? If you meant the statement context of the "VALUES
CURRENT_USER", it has to get its session state from somewhere? (As I understand it, the lifetime
of the statement context is limited to prepare and/or execution of a single statement.)

What about the following case: I think the activations of dynamic result sets may need the
dynamic context after the procedure has returned, say, if the statement yielding the result
set references CURRENT_ROLE and that this is evaluated lazily only when the cursor is accessed
(rs.next()). The statement context for the CALL has been popped (and reset) at that time (from
GEnericPreparedStatement#execute), right? Would it be ok with the current model for it to
stay live until the dynamic result set us closed? If not, perhaps a separate SQLConnectionContext
(which could stay around longer) is better?

Also, since the lcc.getStatementContext returns the current top context, it would not yield
the right one if invoked by a dynamic result set of an activation after procedure return,
I think?

Sorry if I am misconstruing reality here; trying to understand more ;)
  

> 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