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-2264) Restrict shutdown, upgrade, and encryption powers to the database owner
Date Thu, 07 Jun 2007 14:38:26 GMT

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

Dag H. Wanvik updated DERBY-2264:

    Attachment: DERBY-2264-9.stat

Uploading DERBY-2264-9.* which replaces DERBY-2264-8.*

In addition to the changes in #8 which it replaces, it adds code to
address the upgrade snag discussed in the email thread:



When doing temporary soft upgrade boot used to authenticate (first
phase of two phased hard upgrade boot introduced with this issus),
make sure not to check for/activate any new feature in
DataDictionaryImpl#boot / DataDictionaryImpl#checkVersion.

This ensures that the temporary soft upgrade boot will succeed so
authentication and hard upgrade boot can proceed.

I bypass the feature check/activation in DataDictionaryImpl#boot() by
passing in an internal attribute 'softUpgradeNoFeatureCheck' (from
EmbedConnection) when required.

As a consequence, when upgrading from 10.1 or earlier to 10.3 or
later, there will be no check for *database owner* (OK, since
database owner is not yet in created in its post 10.1 form), but
an ordinary credentials check will happen before the hard upgrade
takes place (nice) - so only an authenticated user can upgrade and
become database owner (always assuming authentication is enabled
of course), allowing us to still avoid
"Non-authenticated user gets to upgrade from pre-10.2 version
databases and become database owner".

If upgrading from 10.2 or newer we will be activate SQLAutorization
(if set) during the temporary soft upgrade boot so we can authenticate
database owner.

The second phase will then do the hard upgrade and, if it is from
a pre-10.2 database, create the (new) database owner - as before
with upgrade to 10.2.

Question: Is passing an internal attribute down from
EmbedConnection to DataDictionaryImpl#boot an acceptable way to
implement this solution?  (I do make sure to remove any such
attribute for other cases, in case somebody tries to be clever and
pass it in from the URL..)

I tested this approach and it works as expected for the upgrade
scenarios I have been able to imagine and throw at it, plus derbyall
and suites.All regression tests.

> Restrict shutdown, upgrade, and encryption powers to the database owner
> -----------------------------------------------------------------------
>                 Key: DERBY-2264
>                 URL: https://issues.apache.org/jira/browse/DERBY-2264
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security, SQL
>            Reporter: Rick Hillegas
>            Assignee: Dag H. Wanvik
>             Fix For:
>         Attachments: dbaPowers.html, dbaPowers.html, DERBY-2264-1.diff, DERBY-2264-1.stat,
DERBY-2264-2.diff, DERBY-2264-2.stat, DERBY-2264-3.diff, DERBY-2264-3.stat, DERBY-2264-4.diff,
DERBY-2264-4.stat, DERBY-2264-5.diff, DERBY-2264-5.stat, DERBY-2264-6.diff, DERBY-2264-6.stat,
DERBY-2264-6b.diff, DERBY-2264-6b.stat, DERBY-2264-7.diff, DERBY-2264-7.stat, DERBY-2264-8.diff,
DERBY-2264-8.diff, DERBY-2264-8.stat, DERBY-2264-8.stat, DERBY-2264-9.diff, DERBY-2264-9.stat,
encrypt-1b.sql, encrypt-2.sql, encrypt-3.sql, releaseNote.html
> This JIRA separates out the database-owner powers from the system privileges in the master
security JIRA DERBY-2109. Restrict the following powers to the database owner for the moment:
shutdown, upgrade, and encryption.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message