[
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
DERBY-2264-4.diff
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:
derbyall/derbynetmats/derbynetmats.fail:jdbcapi/setTransactionIsolation.java
derbyall/storeall/storeall.fail:store/readlocks.sql
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.
