db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5507) Orderly shutdown fails if you are using BUILTIN authentication and turn on derby.database.propertiesOnly
Date Mon, 21 Nov 2011 21:30:55 GMT

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

Myrna van Lunteren commented on DERBY-5507:
-------------------------------------------

Unfortunately, the original Cloudscape repository comments do not reference bug trackers for
this change.

I did follow this code snippet (minus the 'derby' clause, of course) through the creation
of the PropertyValidation class from code in the PropertyConglomerate class to its first inclusion
on Aug 27, 1999, by djd, but the only comment on the check-in is: "Lock manager properties"
(cloudscape revision 11958, for reference).

Before that, ValidateAndApplyMap looked like this:

	private Serializable validateApplyAndMap(TransactionController tc,
											 String key, Serializable value)
		 throws StandardException
	{
		Dictionary d = new Hashtable();
		getProperties(tc,d,false/*!stringsOnly*/,false/*!defaultsOnly*/);
		Serializable mappedValue = null;
 		if (notifyOnSet != null) {
			synchronized (this) {

				for (int i = 0; i < notifyOnSet.size() ; i++) {
					PropertySetCallback psc = (PropertySetCallback) notifyOnSet.elementAt(i);
					if (!psc.validate(key, value, d))
						continue;

					Serviceable s;
					if ((s = psc.apply(key,value,d)) != null)
						((TransactionManager) tc).addPostCommitWork(s);
					if (mappedValue == null)
 						mappedValue = psc.map(key, value, d);
				}
			}
		}

		//
		// RESOLVE: log device cannot be changed on the fly right now
		if (key.equals(Attribute.LOG_DEVICE))
			throw RawStoreStatementException.cannotChangeLogDevice();

		if (mappedValue == null)
			return value;
		else
			return mappedValue;
	}


At the time of this change, the method AddPropertySetNotification was also considerably changed,
it had code added that also mentioned those SET_IN_* values/comments; 
                // set up the initial values by calling the validate and apply methods.
		// the map methods are not called as they will have been called
		// at runtime when the user set the property.
                [...more code added...]
				if (!who.validate(key, value, d))
					continue;

				// SET_IN_JVM - need to get value
				// SET_IN_DATABASE - use the stored value
				// SET_IN_APPLICATION - need to get value
				// NOT_SET - can't happen cos it does exist in d

				if (!dbOnly) {
					int whereSet = PropertyUtil.whereSet(key, d);
					if (whereSet != PropertyUtil.SET_IN_DATABASE)
						value = PropertyUtil.getSystemProperty(key);
				}
                   [...]
but that code was subsequently removed again (in cloudscape revision 12007, on Aug 30, 1999,
by djd) with check-in comment:
"Fix bug with missing read lock configuration parameters."

At that time, (in addition to adding of a locks.waitTimeout property), it looks like an init
method was added to PropertySetCallback, to SinglePool, some dummy init methods were added
to some other classes, and PropertyUtil got a new method with signature:
public static String getPropertyFromSet(boolean dbOnly, Dictionary set, String key) 

Perhaps the code snippet in the method doValidateAndApplyMap should also have been removed
at that time?

                
> 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

        

Mime
View raw message