[
https://issues.apache.org/jira/browse/DERBY-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5968:
---------------------------------
Attachment: derby-5968-01-ac-shutdownDatabaseIfBootingConnectionFails.diff
Attaching rev 3 of the patch:
derby-5968-01-ac-shutdownDatabaseIfBootingConnectionFails.diff. The previous
patch tripped a problem in Derby5937SlaveShutdownTest. I will run regression
tests on this patch if people think that its approach is correct.
I believe this is what was happening in Derby5937SlaveShutdownTest:
o The test loops, trying to connect to the master in order to start
replication. For a couple iterations, the connection attempts fail because the
slave has not come up yet.
o With each failed connection attempt, the master database boots and then shuts
down.
o Shutting down the master database moves its log instant forward. This breaks
agreement between the master and slave databases.
o When the slave does come up, it notices that the log instant of the master
has moved forward. Replication fails because the two databases are not in
agreement.
Here are two approaches to this problem:
1) Treat this as a defect in the test. Figure out some way to delay booting the
master until the slave has come up.
2) Treat this as a coding pattern which applications may already rely on. Put
some defensive code in EmbedConnection so that we don't bring down the master
database if the slave has not come up yet.
The third patch implements approach (2). However, I am not convinced that we
should support this application coding pattern. In particular, I think that the
failure to bring down the master database in this case will still leave a
security hole. I would like other people's opinions about whether we should
treat the failure of Derby5937SlaveShutdownTest as a defect in the test rather
than a product bug.
Thanks in advance for your opinions,
-Rick
Touches the following additional files:
----------------
M java/build/org/apache/derbyBuild/MessageBundleTest.java
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
Factor out a SQLState which does not bring down the master database.
----------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/Derby5937SlaveShutdownTest.java
Put a little more debug instrumentation in this test.
> A failed connection attempt may nevertheless manage to boot the database.
> -------------------------------------------------------------------------
>
> Key: DERBY-5968
> URL: https://issues.apache.org/jira/browse/DERBY-5968
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
> Attachments:
> derby-5968-01-aa-shutdownDatabaseIfBootingConnectionFails.diff,
> derby-5968-01-ab-shutdownDatabaseIfBootingConnectionFails.diff,
> derby-5968-01-ac-shutdownDatabaseIfBootingConnectionFails.diff
>
>
> A connection attempt may fail but still manage to boot the database. If
> possible, we should try to bring down the database after the connection
> failure.
> 1) Here is an example of this problem: If you use bad credentials to connect
> to a database, you will fail to get a connection. That's correct behavior.
> However, Derby must boot the database in order to discover its authentication
> mechanism. The database remains booted after this check.
> 2) There are other examples of this problem. For instance, if a user with
> good credentials tries to change the boot password on an encrypted database,
> then the connection attempt will fail, but the database will remain booted.
> This can cause silent failures on later attempts to re-encrypt or un-encrypt
> a database after the low-privilege or nonexistent user manages to boot the
> database. The connection attempt will succeed, leading the DBO to think that
> the re-encryption worked. But actually re-encryption did not take place
> because the database was already booted.
> I regard this silent failure as a security vulnerability.
> The following script shows problem (1):
> connect 'jdbc:derby:db;create=true;user=test_dbo';
> call syscs_util.syscs_create_user( 'test_dbo', 'test_dbopassword' );
> -- shutdown the database
> connect 'jdbc:derby:db;shutdown=true';
> -- need credentials in order to get a connection
> connect 'jdbc:derby:db';
> connect 'jdbc:derby:db;user=test_dbo;password=test_dbopassword';
> select count(*) from sys.systables;
> -- shutdown the database
> connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';
> -- try to shutdown the database again. since it is already shutdown, you will
> get a message saying it can't be found.
> connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';
> -- now try to boot with bad credentials. you don't get a connection but the
> database boots.
> connect
> 'jdbc:derby:db;user=alice;password=alicepassword;bootPassword=foobarwibblewombat';
> select count(*) from sys.systables;
> -- the shutdown command succeeds because alice managed to boot the database
> -- even though she isn't a legal user.
> connect 'jdbc:derby:db;shutdown=true;user=test_dbo;password=test_dbopassword';
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
