db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5968) A failed connection attempt may nevertheless manage to boot the database.
Date Wed, 07 Nov 2012 13:57:12 GMT

    [ 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

Mime
View raw message