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] Updated: (DERBY-3327) SQL roles: Implement authorization stack (and SQL session context to hold it)
Date Tue, 03 Jun 2008 22:54:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dag H. Wanvik updated DERBY-3327:
---------------------------------

    Attachment: DERBY-3327-6.stat
                DERBY-3327-6.diff

Uploading DERBY-3327-6, which removes a sanity check from
GenericLanguageConnectionContext.

In GenericLanguageConnectionContext#getInitialDefaultSchemaDescriptor there was
a sanity check that the initial default schema value is always computed before
it is ever used by getDefaultSchema; that proved to not be the case in one code
path, cf. indicative check for null in DataDictionaryImpl#getSchemaDescriptor
near the end of that method.

When chasing the recursion in the printing of the lock table for DERBY-3678 I
noticed that the assert error was triggered, which removed the recursion at the
expense of the lock table being incompetely filled in as below (notice default
values, e.g. for CONTAINER_ID column);

|STATE|TABLETYPE / LOCKOBJ |INDEXNAME / CONTAINER_ID / (MODE for LATCH only)  |TABLENAME /
CONGLOM_ID |
------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
151       |ROW          |S   |0        |(1,18) |WAIT |org.apache.derby.impl.services.locks.A|CONTAINERID
|CONGLOMID |
:

(The assert error was silently swallowed in TimeOut#buildLockTableString, see
 the comment "//just don't do anything".


If this is a valid code path or not I have yet to determine, but I remove the
sanity check for now; so the sane build will not work better than the insane.

Regressions ran OK, module wisconsin, which i believe to be unrelated.


> SQL roles: Implement authorization stack (and SQL session context to hold it)
> -----------------------------------------------------------------------------
>
>                 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.5.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, DERBY-3327-4-full-b.diff, DERBY-3327-4-full-b.stat,
DERBY-3327-4-full-c.diff, DERBY-3327-4-full-c.stat, DERBY-3327-4-full-d.diff, DERBY-3327-4-full-d.stat,
DERBY-3327-4-full-e-10_4.diff, DERBY-3327-4-full-e-10_4.stat, DERBY-3327-4-full-e.diff, DERBY-3327-4-full-e.stat,
DERBY-3327-4-full.diff, DERBY-3327-4-full.stat, derby-3327-5a-extracted_initial_schema_patch.diff,
DERBY-3327-6.diff, DERBY-3327-6.stat, releaseNote.html
>
>
> 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 and 10.4 GR 5h and i.
> 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.

> The authorization stack will be implemented as part of the SQL session context.
> The patch will also implement the pushing of the current unqualified schema name part
of
> the SQL session context, cf. 10.4 GR 5a (DERBY-1331).

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