[
https://issues.apache.org/jira/browse/DERBY-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492349#comment-13492349
]
Rick Hillegas commented on DERBY-5968:
--------------------------------------
Tests passed cleanly for me on
derby-5968-01-ac-shutdownDatabaseIfBootingConnectionFails.diff except for two
known heisenbugs. I tried running the failed tests standalone 10 times apiece
but the errors did not recur. The heisenbugs are:
DERBY-5941
DERBY-5942 - For this one, the stack trace is slightly different, perhaps
because of the patch which Kristian committed for DERBY-5942.
Here is the failure report:
There were 2 failures:
1)
testPingWithWrongHost(org.apache.derbyTesting.functionTests.tests.derbynet.NetworkServerControlClientCommandTest)junit.framework.AssertionFailedError:
Could not find expectedString:Unable to find host in output:<STDOUT>Tue Nov 06
13:48:02 PST 2012 : Could not connect to Derby Network Server on host
nothere.invalid, port 1527: Operation timed out
<END STDOUT>
<STDERR><END STDERR>
at
org.apache.derbyTesting.junit.BaseTestCase.assertExecJavaCmdAsExpected(BaseTestCase.java:524)
at
org.apache.derbyTesting.functionTests.tests.derbynet.NetworkServerControlClientCommandTest.assertFailedPing(NetworkServerControlClientCommandTest.java:148)
at
org.apache.derbyTesting.functionTests.tests.derbynet.NetworkServerControlClientCommandTest.testPingWithWrongHost(NetworkServerControlClientCommandTest.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
2)
testInvalidLDAPServerConnectionError(org.apache.derbyTesting.functionTests.tests.jdbcapi.InvalidLDAPServerAuthenticationTest)junit.framework.AssertionFailedError
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.InvalidLDAPServerAuthenticationTest.testInvalidLDAPServerConnectionError(InvalidLDAPServerAuthenticationTest.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
FAILURES!!!
Tests run: 13716, Failures: 2, Errors: 0
> 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
