[
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
