The tuning guide says that a system-wide property set on the command line overrides the same property if set as a database property. Fair enough, since this allows you to override a previously set database property temporarily by setting the property on the command-line.
However, it does not say what happens when you actually set a database property, and at the same time override the property with a system property. From what I can tell from using a debugger, it seems that:
- when the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY procedure is called/prepared, the doValidateApplyAndMap() method in o.a.d.iapi.services.property.PropertyValidation.java "applies" and "maps" the new property only if the same property is not also set in the JVM (SET_IN_JVM, line 73).
- the hashing of the password occurs in the "map" method that is being called.
- when the property is also set as a JVM property, "apply" and "map" is not called, but the property is set as a database property anyway.
I am not sure what "apply" and "map" actually means (the javadoc for PropertySetCallback.map() says "Map a proposed new value for a property to an official value."), but intuitively I find it odd that the property is set in this case without being hashed ("mapped"). Stretching it, I may be able to see how someone could argue that this is not a bug, but in that case it should be made very clear in the manuals how this works.
As indicated earlier, there are two major implications of this issue:
1) Users may think the password is stored securely (hashed) in the database, but it is actually stored in cleartext.
2) The current functionality may also lead to authentication failures later on if the property is no longer overridden in the JVM, since upon authentication the property from the database, which was stored in cleartext, is compared against a hashed password supplied by the user, as seen in
Opinions are welcome. I hope we can get this cleaned up at some point not too far into the future...