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 Tue, 20 Feb 2007 20:10:05 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-1.diff

Right, it seems both Dan and Rick are less concerned than me about the 
compatibility here issue, so I rest my case.

This patch, DERBY-2264-1.{stat,diff} implements a first part of this
JIRA, the checking of shutdown power as specified in the functional
specification. That is, if derby.connection.requireAuthentication
true, only the database owner ia allowed to shut down a database, see

A new test jdbcapi/DboPowersTest.java is added which checks the
enforcement. It runs in both embedded and client/Server frameworks,
and should be runnable in JSR169, too, although I have no tried
this. The idea is to add more tests to DboPowersTest.java as the work
on this issue proceeds, but it works now for shutdown, so I added it
to _Suite.java.

After some head-scratching (how to stack decorators, mainly, and how
they interact) I was able to use the current JUnit decorators to run
the tests, but found two issues, one of which I corrected:

a) When using DatabasePropertyTestSetup.builtinAuthentication, the
enforcement implemented in this patch causes problems for the
decorator's shutdown database action, unless I prepend "APP" to the
list of users. I had to do this for NistScripts.java as well. The
problem occurs because the wombat database was created using APP as
owner. We might want to either document this in the decorator, add an
"APP" user silently, or do something else.

b) The second issue I found was that in wrapping
TestConfiguration.clientServerDecorator around a test which is already
decorated with sqlAuthorizationDecorator, an initial empty password
used by sqlAuthorizationDecorator when constructing
DatabaseChangeSetup does not work with the client (DRDA limitation I
believe), so I changed this to a dummy password with no ill effects.

In addition to the aforementioned NistScripts, I had to also modify
jdbcapi/users.sql, jdbcapi/users2.sql and jdbcapi/secureUsers.sql.
These three had to be modifed to make sure the database owner
performed the shutdowns.

I suspect that secureUsers.sql had probably never really worked as
intended in that the database derbySchemeDB was never rebooted as the
comment says it should be, due to an authentication issue. When I
fixed this, the test failed, because authentication was turned off,
since this property was no longer valid as inherited from the system
properties, when derby.database.propertiesOnly took effect after the
reboot. Not sure what the author intended here; I made it work with
the reboot.

I have run derbyall on Sun's JDK6 on Solaris 10 x86, with only one
error in a compress test, which seems to be an intermittent failure.

I ran the JUnit suites.all on Sun's JDK6 Solaris 11 x86 with no
errors (6814 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
>         Assigned To: Dag H. Wanvik
>         Attachments: dbaPowers.html, dbaPowers.html, DERBY-2264-1.diff, DERBY-2264-1.stat
> 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