You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org> on 2011/12/16 15:38:31 UTC

[jira] [Commented] (DERBY-5507) Orderly shutdown fails if you are using BUILTIN authentication and turn on derby.database.propertiesOnly

    [ https://issues.apache.org/jira/browse/DERBY-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170994#comment-13170994 ] 

Knut Anders Hatlen commented on DERBY-5507:
-------------------------------------------

Thanks for digging through the old code, Myrna. I think I understand now.

Our documentation says that system properties take precedence over database properties. This code is in place to ensure that setting a database property does not override the value in the system property. Currently, only the lock manager properties and the derby.database.classpath property have implemented a PropertySetCallback.apply() method, so that's probably what the "Lock manager properties" commit message referred to. If the call to apply() had not been skipped, setting the lock timeout as a database property would have overridden the lock timeout that was already set as a system property.

It's not the call to PropertySetCallback.apply() that causes problems for us, but rather the call to PropertySetCallback.map(). The comment in the code only mentions that apply() shouldn't be called. No mentioning of map():

					// if this property should not be used then
					// don't call apply.

I believe calling map(), also in the case where we don't call apply(), would be the right thing to do. Since we're storing the property in the database (although not actually using the value until the database is rebooted without the system property set), we must store the correct value. And to store the correct value, we need to perform the mapping.

Since AuthenticationServiceBase is the only class that implements a map() method that's not a no-op, making that change should only affect the password properties, so it sounds like a limited and relatively safe change to make.
                
> Orderly shutdown fails if you are using BUILTIN authentication and turn on derby.database.propertiesOnly
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5507
>                 URL: https://issues.apache.org/jira/browse/DERBY-5507
>             Project: Derby
>          Issue Type: Bug
>          Components: Miscellaneous
>    Affects Versions: 10.9.0.0
>            Reporter: Rick Hillegas
>
> The following script raises an assertion on the last line. We are failing during the encryption of the password. The assertion prints out the plaintext of the password. I ran the script with the following command line:
> java \
>   -Dderby.connection.requireAuthentication=true  \
>   -Dderby.authentication.provider=BUILTIN \
>   -Dderby.user.test_dbo=test_dbopassword \
>   org.apache.derby.tools.ij $SCRIPT
> Here is the script:
> connect 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword';
> call syscs_util.syscs_set_database_property( 'derby.connection.requireAuthentication', 'true' );
> call syscs_util.syscs_set_database_property( 'derby.authentication.provider', 'BUILTIN' );
> -- shutdown works correctly if you comment out the following two lines
> call syscs_util.syscs_set_database_property( 'derby.user.test_dbo', 'test_dbopassword' );
> call syscs_util.syscs_set_database_property( 'derby.database.propertiesOnly', 'true' );
> -- fails to authenticate correct credentials
> connect 'jdbc:derby:memory:db;shutdown=true;user=test_dbo;password=test_dbopassword';
> Here is the assertion printed on the screen:
> ERROR XJ001: Java exception: 'ASSERT FAILED Unknown authentication scheme for token test_dbopassword: org.apache.derby.shared.common.sanity.AssertFailure'.
> Here is the stack trace in derby.log:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Unknown authentication scheme for token test_dbopassword
> 	at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> 	at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> 	at org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl.encryptPasswordUsingStoredAlgorithm(BasicAuthenticationServiceImpl.java:282)
> 	at org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl.authenticateUser(BasicAuthenticationServiceImpl.java:199)
> 	at org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.authenticate(AuthenticationServiceBase.java:279)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(EmbedConnection.java:1220)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:422)
> 	at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
> 	at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:51)
> 	at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70)
> 	at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255)
> 	at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:143)
> 	at java.sql.DriverManager.getConnection(DriverManager.java:582)
> 	at java.sql.DriverManager.getConnection(DriverManager.java:154)
> 	at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:1528)
> 	at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:1358)
> 	at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:1143)
> 	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:347)
> 	at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:245)
> 	at org.apache.derby.impl.tools.ij.Main.go(Main.java:229)
> 	at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184)
> 	at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
> 	at org.apache.derby.tools.ij.main(ij.java:59)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira