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 Mon, 21 Jan 2008 15:11:34 GMT

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

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

Thanks for looking at this, Knut!

a) naming: Sounds like a good idea. You OK with that, Rick?

b) Yes, Stack is a bit heavy being based on Vector. I was looking at
   Deque which is the recommended stack abstraction, 
   (cf. comment at top of http://java.sun.com/javase/6/docs/api/java/util/Stack.html:

    "...A more complete and consistent set of LIFO stack operations is
     provided by the Deque interface and its implementations, which
     should be used in preference to this class."

   but it is not available in 1.4, so ArrayList, although less
   descriptive, is sufficient and probably the better choice here, I
   agree.


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