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 Wed, 07 Mar 2007 00:07:24 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-4.stat

This patch (DERBY-2264-4.{diff,stat}) adds policing of powers for
(re)encryption and adds tests for this.

I also extended the JUnit framework with some new methods.

I ran derbyall on Solaris 10, x86, Sun Java 1.6, with two errors,
which I think are unrelated:


The JUnit suites.All ran to completion, no failures.

* A note on atomicity of encrypting:

Currently, the boot and the simultaneous (re)encryption is atomic, as
far as I understand, so another thread (#2) will either a) boot first,
making the encrypting boot (thread #1) silently fail *or* b) be
blocked by the encrypting boot and get a connection after the
encryption is done (i.e. we have atomicity).

The new thing introduced by this patch is that thread #11 (the
encrypting connection thread) does three atomic steps ( [1] boot, [2]
shutdown, [3] boot/encrypt) in stead of previously one (boot/encrypt).
We may need/want to make those three into one atomic operation
somehow, to avoid a race condition.

Currently, there is no synchronization between connections before one
hits the booting level as far as I can see (?).  In the constructor of
EmbedConnection, which is where the new enforcement boot/shutdown/boot
logic is located, there is no synchronization across connections
currently. We may have to introduce something to make the three
operations atomic; I would appreciate others' opinion on this, I will
make a follow-up patch if synchronization is deemed necessary.

Race scenarios:

If thread #2 sneaks in between [1] and [2] it will lose its
connection, which thread #1 shuts down the database in step [2].

If thread #2 sneaks in between [2] and [3], the (re)encryption of
thread #1 in step [3] will silently (see DERBY-2409) fail.

The first scenario is new and could be seen by applications. I am not
sure it is really necessary to synchronize this further, though, since
essentially, to (re)encrypt a DBA needs to shut down the database and
make sure other connections don't re-boot the database in the
meantime, in any case. In summary, I think it's an edge case.

> 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
>         Assigned To: Dag H. Wanvik
>         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, encrypt-1b.sql, encrypt-2.sql, encrypt-3.sql
> 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