[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-24-aa-dboMustTurnOnSecurity.diff Attaching derby-866-24-aa-dboMustTurnOnSecurity.diff. This patch forbids another weird Derby behavior when NATIVE authentication is involved. I am running tests now. The weird behavior is this: If authentication and authorization are not on, then any legal user can hijack the database by turning them on and specifying credentials which lock out everyone else. This patch prevents an insider from using NATIVE authentication to do this. Because of backward compatibility, I am reluctant to close down this behavior for other authentication schemes. But since NATIVE authentication has not gone GA yet, we have the opportunity to make it behave better. More exactly, this patch enforces the restriction that only the DBO can turn on NATIVE authentication. We can relax this restriction in the future if someone comes up with a supporting use case. However, right now this looks like a security hole to me. Touches the following files: --- M java/engine/org/apache/derby/catalog/SystemProcedures.java The new check to let only the DBO turn on NATIVE authentication. --- M java/engine/org/apache/derby/loc/messages.xml Slight rewording of an existing error message so that is can be re-used for this check. --- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java New test case to verify the new behavior. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff, derby-866-22-aa-dboFirst.diff, derby-866-23-aa-improveErrorMessages.diff, derby-866-24-aa-dboMustTurnOnSecurity.diff, dummyCredentials.properties, releaseNote.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- This message is automatically generated by JIRA. If you think it was sent
[jira] [Updated] (DERBY-5640) Use desc element for table summary
[ https://issues.apache.org/jira/browse/DERBY-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5640: - Attachment: rrefexcept71493.dita derby-5640-01-aa-messageBuilder.diff Your instincts about what to do with MessageBuilder sound right to me, Kim. Attaching derby-5640-01-aa-messageBuilder.diff, which does just what you said. Also attaching the corresponding output: rrefexcept71493.dita. Let me know if this looks right to you. Thanks, -Rick Use desc element for table summary Key: DERBY-5640 URL: https://issues.apache.org/jira/browse/DERBY-5640 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.8.2.2, 10.9.0.0 Reporter: Kim Haase Assignee: Kim Haase Priority: Minor Fix For: 10.8.2.2 Attachments: DERBY-5640-2.diff, DERBY-5640-2.stat, DERBY-5640-2.zip, DERBY-5640-3.diff, DERBY-5640-3.stat, DERBY-5640-3.zip, DERBY-5640-4.diff, DERBY-5640-4.stat, DERBY-5640-4.zip, DERBY-5640-5.diff, DERBY-5640-5.stat, DERBY-5640-5.zip, DERBY-5640-6.diff, DERBY-5640-6.stat, DERBY-5640-6.zip, DERBY-5640-7.diff, DERBY-5640-7.stat, DERBY-5640-7.zip, DERBY-5640-8.diff, DERBY-5640-8.stat, DERBY-5640-8.zip, DERBY-5640.diff, DERBY-5640.stat, DERBY-5640.zip, derby-5640-01-aa-messageBuilder.diff, rrefexcept71493.dita Currently we provide table summaries by putting the table caption in the summary. However, the desc element should be used for this purpose. -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: releaseNote.html Attaching the first rev of a release note for this issue. Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff, derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff, derby-5493-01-af-usersubtran.diff, derby-5493-01-ag-mergedWith5494.diff, derby-5493-02-aa-boostPreallocationTo100.diff, releaseNote.html The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: derby-5493-01-ag-mergedWith5494.diff Attaching derby-5493-01-ag-mergedWith5494.diff. This is the patch after syncing with the trunk and merging with Mike's fix to DERBY-5494. At this point the tests run cleanly. However, as Mike suspected, concurrency has returned to the situation with the 01-ae patch, what was reported on DERBY-5471. In a follow-on patch, I think I will boost the pre-allocation size to 100 unless someone objects. Committed at subversion revision 1327471. Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff, derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff, derby-5493-01-af-usersubtran.diff, derby-5493-01-ag-mergedWith5494.diff The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: derby-5493-02-aa-boostPreallocationTo100.diff Attaching derby-5493-02-aa-boostPreallocationTo100.diff. This boosts the preallocation size to 100 in order to get slightly better concurrency than we saw in 10.8. Tests passed cleanly for me. Committed at subversion revision 1327682. Touches the following files: -- M java/engine/org/apache/derby/impl/sql/catalog/SequenceRange.java The actual change. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/SequenceGeneratorTest.java Boosting the preallocation size caused a combinatorial explosion in the number of cases stressed in the boundary test for sequences. I pared that test back to a manageble set of cases. Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff, derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff, derby-5493-01-af-usersubtran.diff, derby-5493-01-ag-mergedWith5494.diff, derby-5493-02-aa-boostPreallocationTo100.diff The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- 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
[jira] [Updated] (DERBY-5471) Stress test for identity columns and sequence seem to be taking longer on trunk compared to 10.8.2.2 RC3
[ https://issues.apache.org/jira/browse/DERBY-5471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5471: - Attachment: 5471-performance.html Attaching 5471-performance.html, a report on concurrency tests I ran on a 32-cpu machine, using Java 7 with the write-cache disabled. I ran the tests with 3 codelines: 10.8.2.2, current trunk, and trunk plus the derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff patch. For identity columns, the results are simple: throughput stays constant regardless of the codeline. For sequences, the results are more complicated: o Throughput goes up in the current trunk, presumably because the default pre-allocation size is 20 on the trunk, vs. 5 in 10.8.2.2. o However, throughput drops significantly with the 5493 patch. o By boosting the pre-allocation size to 100, throughput again goes above 10.8.2.2 levels. I will see if I can adjust the patch to get better throughput numbers for sequences. I expect that I will discuss those experiments on derby-5493. Stress test for identity columns and sequence seem to be taking longer on trunk compared to 10.8.2.2 RC3 Key: DERBY-5471 URL: https://issues.apache.org/jira/browse/DERBY-5471 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.9.0.0 Environment: Windows XP version 2.18 Genuine Intel(R) CPU T2600 dual core @2.16GHz 2.00GB of RAM $ java -version java version 1.6.0 Java(TM) SE Runtime Environment (build pwi3260sr9fp1-20110208_03(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr9-201102 03_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 Reporter: Mamta A. Satoor Attachments: 5471-performance.html I have been trying to run org.apache.derbyTesting.perf.clients.Runner (which provides ways to stress test sequence generator and identity columns) on trunk and 10.8.2.2 RC3 to compare the performance and I find that it takes almost double the time for the tests to finish on trunk. Additionally, the identity column test consistently ran into lock timeouts on trunk. I am running with insane jars on trunk and 10.8.2.2 RC3. The test in question is not in official jars for the release candidate so I manually copied them to 10.8.2.2 RC3 environment during my test(basically copied the entire org.apache.derbyTesting.perf.clients.Runner directory from trunk to 10.8.2.2 RC3 environment). Command to do sequence stress testing is as follows java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100,identityTest=0 -gen b2b -threads 10 Command to do identity column stress testing is as follows time java org.apache.derbyTesting.perf.clients.Runner -driver org.apache.derby.jdbc.EmbeddedDriver -init -load seq_gen -load_opts debugging=1,numberOfGenerators=5,tablesPerGenerator=10,insertsPerTransaction=100,identityTest=1 -gen b2b -threads 10 An average run on 10.8.2.2 RC3 for sequence stress test is about a minute and 46 secs. On trunk, on an average it takes 2 and half minutes An average run on 10.8.2.2 RC3 for identity stress test is about a minute and 50 secs. On trunk, on an average it takes 3minsutes and 30 secs. Also, on trunk, this test runs into lock timeouts. I was wondering if this is the right behavior. The performance should be better in trunk because of pre-allocation of range for sequences and identity columns(which defaults to 20) but unless I have missed something in my tests, the results don't show the performance improvement. -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: derby-5493-01-af-usersubtran.diff Attaching derby-5493-01-af-usersubtran.diff. This patch fixes the concurrency problems with the previous patch which were disclosed by the experiments described on DERBY-5471. The fix is to go back to updating SYSSEQUENCES in a subtransaction of the user's execution transaction. This means that this patch does not fix DERBY-5494. So I won't commit this patch until Mike commits his work on DERBY-5494. At that point, I will adjust the patch to account for the fact that Mike is going to include the regression test case for that issue which was introduced by the earlier rev of this patch. With this version of the patch the tx/sec results are slightly better than the comparable experiments on 10.8.2.2 and trunk: o 10 threads with preallocation=20: 99 vs 92 on trunk o 10 threads with preallocation=5: 78 vs 75 on 10.8.2.2 o 1 thread with preallocation=20: 45 vs 44 on trunk o 1 thread with preallocation=5: 36 vs 35 on 10.8.2.2 Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff, derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff, derby-5493-01-af-usersubtran.diff The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- 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
[jira] [Updated] (DERBY-5690) Give users a way to run an ij script programmatically so they can filter errors.
[ https://issues.apache.org/jira/browse/DERBY-5690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5690: - Attachment: StatementReader.java Attaching StatementReader.java. This class can be used to parse a batch of sql statements the way that ij does. You construct an instance of this class from an InputStream (e.g., a FileInputStream created from your statement batch) and then you loop, calling StatementReader.nextStatement() to drain the batch. Each nextStatement() call returns a single statement. The final call returns null. Give users a way to run an ij script programmatically so they can filter errors. Key: DERBY-5690 URL: https://issues.apache.org/jira/browse/DERBY-5690 Project: Derby Issue Type: Improvement Components: Tools Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: StatementReader.java Sometimes users need a way to run an ij script programmatically and handle the errors. It would be nice if they could use ij's StatementFinder to parse a semi-colon delimited file of sql statements, throwing away comments. StatementFinder itself can't be used because it is not part of the public api and it has some small dependencies on other Derby code. I will attach a standalone class which applications can use. -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff Attaching derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff. This is identical to the previous patch except that it adds a JUnit test case to verify the fix to DERBY-5494, using assertLaunchedJUnitTestMethod as Mike suggested. This test case could be added to the fix for DERBY-5494 which Mike is working on. Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff, derby-5493-01-ae-simplerApproachWithCrashJUnitTest.diff The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: derby-5493-01-ad-simplerApproach.diff Attaching derby-5493-01-ad-simplerApproach.diff. This patch is not ready for commit. I want to run some throughput tests with it first. The patch implements the approach which we seem to have converged on: 1) Retains the syscs_peek_at_sequence() function so that users can get the instantaneous value of a sequence without having to query SYSSEQUENCES. I changed the signature of this function. Instead of a single uuid argument, the function now takes a schema and sequence name pair. The idea here is to not tempt users into driving this function with a select from SYSSEQUENCES in order to get the uuid. 2) Instead of using an invisible conglomerate, pre-allocation happens in the SYSSEQUENCES row (as in 10.8). 3) Pre-allocation is done by a transaction which is dedicated to the sequence. The transaction expects to do its work immediately, without waiting for a lock, and then to autocommit that work. If the transaction can't get a lock immediately, it raises a TOO MUCH CONTENTION exception. We seem to agree that TOO MUCH CONTENTION can only arise if sequence DDL is in flight or if the application scans SYSSEQUENCES against our advice. I tried a slightly different approach at first. In that approach, pre-allocation happened in a sub-transaction of the session's execution transaction. That approach fixed this bug (DERBY-5493) but did not fix DERBY-5494. By using a separate, dedicated transaction, I am able to fix DERBY-5494 as well. Touches the following files: -- M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/catalog/SystemProcedures.java Support for the new syscs_peek_at_sequence() function. -- M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java I changed the wording of the TOO MUCH CONTENTION exception so that it points the user at the likely cause of the problem: an open scan of SYSSEQUENCES. I changed this exception to Transaction severity so that the language layer does not get confused during cleanup. -- M java/engine/org/apache/derby/impl/sql/catalog/SequenceUpdater.java Re-plumbed the SequenceUpdater as described above. -- M java/engine/org/apache/derby/impl/sql/catalog/SequenceGenerator.java Adjusted the wording of some comments. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/GeneratedColumnsHelper.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/SequenceGeneratorTest.java A java/testing/org/apache/derbyTesting/functionTests/tests/lang/t_5494.sh M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java Tests for the new system function and to verify the fixes to the correctness problems. -- M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_2.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/GrantRevokeDDLTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/TestDbMetaData.java M java/testing/org/apache/derbyTesting/functionTests/master/ij7.out Tests which had to change to account for the new system function. Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff, derby-5493-01-ad-simplerApproach.diff The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please
[jira] [Updated] (DERBY-5687) Back out the concurrency improvements for identity columns introduced by derby-4437
[ https://issues.apache.org/jira/browse/DERBY-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5687: - Attachment: derby-5687-01-aa-backOutImprovement.diff Attaching derby-5687-01-aa-backOutImprovement.diff. This patch backs out concurrency improvements introduced by DERBY-4437. Regression tests passed cleanly for me. Committed at subversion 1311285. More specifically, this patch backs out the following patches: derby-4437-01-aj-allTestsPass.diff The main patch which ported the work on sequences to identity columns. derby-4437-02-ac-alterTable-bulkImport-deferredInsert.diff Test cases to verify that the port did not break various features. derby-4437-03-aa-upgradeTest.diff Upgrade/downgrade tests for the port. Touches the following files: M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/impl/sql/compile/CreateSequenceNode.java M java/engine/org/apache/derby/impl/sql/compile/NextSequenceNode.java M java/engine/org/apache/derby/impl/sql/execute/InsertResultSet.java M java/engine/org/apache/derby/impl/sql/execute/BaseActivation.java M java/engine/org/apache/derby/impl/sql/execute/InsertConstantAction.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/sql/catalog/SequenceUpdater.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/iapi/sql/dictionary/SequenceDescriptor.java M java/engine/org/apache/derby/iapi/reference/Property.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AlterTableTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AutoIncrementTest.java D java/testing/org/apache/derbyTesting/functionTests/tests/lang/t_4437_2.dat M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java Back out the concurrency improvements for identity columns introduced by derby-4437 --- Key: DERBY-5687 URL: https://issues.apache.org/jira/browse/DERBY-5687 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: derby-5687-01-aa-backOutImprovement.diff DERBY-4437 attempted to improve the concurrency of identity columns by using SYSSEQUENCE-style sequence generators. These improvements caused NsTest to behave differently than it used to and they disclosed a problem in clearing the identity cache. The community lost confidence in this solution and it was backed out of the 10.8 branch under issue DERBY-5448. This new issue is filed to back the improvements out of the 10.9 trunk. Further useful discussion about how to improve the concurrency and correctness of identity columns has been taking place on DERBY-5443 and DERBY-5493. For the 10.9 release, identity columns will return to their old behavior of being ill-suited for high concurrency applications. Applications which need higher concurrency should be re-coded to use sequences rather than identity columns. -- 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
[jira] [Updated] (DERBY-5687) Back out the concurrency improvements for identity columns introduced by derby-4437
[ https://issues.apache.org/jira/browse/DERBY-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5687: - Attachment: derby-5687-02-aa-publicAPI.diff Attaching derby-5687-02-aa-publicAPI.diff. This patch adjusts the javadoc for SequencePreallocator, which appears in Derby's public API. The patch removes references to identity columns so that the javadoc now only talks about sequences. Committed at subversion revision 1311310. Touches the following file: M java/engine/org/apache/derby/catalog/SequencePreallocator.java Back out the concurrency improvements for identity columns introduced by derby-4437 --- Key: DERBY-5687 URL: https://issues.apache.org/jira/browse/DERBY-5687 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: derby-5687-01-aa-backOutImprovement.diff, derby-5687-02-aa-publicAPI.diff DERBY-4437 attempted to improve the concurrency of identity columns by using SYSSEQUENCE-style sequence generators. These improvements caused NsTest to behave differently than it used to and they disclosed a problem in clearing the identity cache. The community lost confidence in this solution and it was backed out of the 10.8 branch under issue DERBY-5448. This new issue is filed to back the improvements out of the 10.9 trunk. Further useful discussion about how to improve the concurrency and correctness of identity columns has been taking place on DERBY-5443 and DERBY-5493. For the 10.9 release, identity columns will return to their old behavior of being ill-suited for high concurrency applications. Applications which need higher concurrency should be re-coded to use sequences rather than identity columns. -- 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
[jira] [Updated] (DERBY-5687) Back out the concurrency improvements for identity columns introduced by derby-4437
[ https://issues.apache.org/jira/browse/DERBY-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5687: - Attachment: derby-5687-03-aa-adjustUserDocs.diff Attaching derby-5687-03-aa-adjustUserDocs.diff. This patch adjusts the reference guide so that it no longer mentions identity columns when discussing sequence pre-allocators. Committed at subversion revision 1311312. Touches the following files: M src/ref/rrefsqlj37836.dita M src/ref/rrefsqljcreatesequence.dita M src/ref/rrefproperpreallocator.dita Back out the concurrency improvements for identity columns introduced by derby-4437 --- Key: DERBY-5687 URL: https://issues.apache.org/jira/browse/DERBY-5687 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: derby-5687-01-aa-backOutImprovement.diff, derby-5687-02-aa-publicAPI.diff, derby-5687-03-aa-adjustUserDocs.diff DERBY-4437 attempted to improve the concurrency of identity columns by using SYSSEQUENCE-style sequence generators. These improvements caused NsTest to behave differently than it used to and they disclosed a problem in clearing the identity cache. The community lost confidence in this solution and it was backed out of the 10.8 branch under issue DERBY-5448. This new issue is filed to back the improvements out of the 10.9 trunk. Further useful discussion about how to improve the concurrency and correctness of identity columns has been taking place on DERBY-5443 and DERBY-5493. For the 10.9 release, identity columns will return to their old behavior of being ill-suited for high concurrency applications. Applications which need higher concurrency should be re-coded to use sequences rather than identity columns. -- 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
[jira] [Updated] (DERBY-5687) Back out the concurrency improvements for identity columns introduced by derby-4437
[ https://issues.apache.org/jira/browse/DERBY-5687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5687: - Attachment: derby-5687-03-aa-adjustUserDocs.diff Re-attaching the user docs changes in order to grant the license to ASF. Back out the concurrency improvements for identity columns introduced by derby-4437 --- Key: DERBY-5687 URL: https://issues.apache.org/jira/browse/DERBY-5687 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: derby-5687-01-aa-backOutImprovement.diff, derby-5687-02-aa-publicAPI.diff, derby-5687-03-aa-adjustUserDocs.diff, derby-5687-03-aa-adjustUserDocs.diff DERBY-4437 attempted to improve the concurrency of identity columns by using SYSSEQUENCE-style sequence generators. These improvements caused NsTest to behave differently than it used to and they disclosed a problem in clearing the identity cache. The community lost confidence in this solution and it was backed out of the 10.8 branch under issue DERBY-5448. This new issue is filed to back the improvements out of the 10.9 trunk. Further useful discussion about how to improve the concurrency and correctness of identity columns has been taking place on DERBY-5443 and DERBY-5493. For the 10.9 release, identity columns will return to their old behavior of being ill-suited for high concurrency applications. Applications which need higher concurrency should be re-coded to use sequences rather than identity columns. -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Issue fix info: Patch Available,Release Note Needed Bug behavior facts: Deviation from standard,Wrong query result Same value returned by successive calls to a sequence generator. Key: DERBY-5493 URL: https://issues.apache.org/jira/browse/DERBY-5493 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_9 Attachments: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff The following script shows the same value being returned from a sequence generator by two successive NEXT VALUE FOR calls. Thanks to Knut for finding this: connect 'jdbc:derby:memory:db;create=true'; create table t (x int); create sequence s; autocommit off; select count(*) from sys.syssequences with rs; values next value for s; drop table t; rollback; -- same value as previous call values next value for s; -- 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
[jira] [Updated] (DERBY-5493) Same value returned by successive calls to a sequence generator.
[ https://issues.apache.org/jira/browse/DERBY-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5493: - Attachment: derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff Attaching derby-5493-01-aa-correctnessPlusPeekerPlusTest.diff. This patch modifies how we allocate new sequence values, in order to fix the known correctness problems with sequence generation. Regression tests pass cleanly for me, but this patch is not ready for commit. It needs additional tests to verify correctness, upgrade, and new user-visible features. Mike and I discussed the correctness problems on DERBY-5443. Two proposals were put forward, each of which had its own messy issues: 1) Use an invisible conglomerate and dedicated transaction to allocate new sequence ranges. This is the approach taken by this patch. 2) Restrict the isolation level used to read from SYSSEQUENCES. In that discussion, two problems with approach (1) were identified: i) It creates a new file (the invisible conglomerate). I think that the space occupied by this new file is very small compared to the size of an empty Derby database and well within the growth we have tolerated for Derby feature releases over the last 7 years. ii) Orphaned tuples can pile up in the invisible conglomerate after successful DROP SEQUENCE and unsuccessful CREATE SEQUENCE statements. I addressed this problem by garbage-collecting the orphans at database boot time. In addition to fixing the known correctness problem, this patch introduces the following user-visible changes: A) A new system function has been added: syscs_peek_at_sequence(). This function gives the application the instantaneous current value of the sequence. In previous releases, users tried to get this information by querying SYSSEQUENCES.CURRENTVALUE. But that didn't work because that column holds the end of the pre-allocation range and not the actual next value in the sequence. B) SYSCONGLOMERATES.TABLEID is now nullable. C) A new SYSGHOST conglomerate is listed in SYSCONGLOMERATES. The SYSGHOST conglomerate does not belong to any corresponding table. Although users can't see it, this is the shape of a SYSGHOST tuple: ( keycol varchar( 32672 ), payload Formatable ) In addition, this patch introduces a testing/diagnostic feature which we should not document: D) A new GhostTable VTI has been added. This lets you view the contents of SYSGHOST. The VTI does all of its work in the transaction controller that is dedicated to managing SYSGHOST. Here's how you invoke it: select * from new org.apache.derby.diag.GhostTable() vti; Behind the scenes, this patch introduces some other new objects: E) GhostController, a synchronized object for reading/writing SYSGHOST tuples. F) A new Formatable to hold the end of a pre-allocation range: SequenceState. G) A new sequence updater for use on databases at level 10.9 or higher: SyssequenceUpdater_10_9. Most of the complexity of the patch is in the implementation of GhostController. Extra support code was added to DataDictionaryImpl and SyssequenceUpdater_10_9, but I tried to isolate most of the trickiness in GhostControllerImpl. This patch will require some changes to the Reference Manual: DOC-1) Add a section describing the new syscs_peek_at_sequence() function. DOC-2) Modify the section on SYSCONGLOMERATES to state that TABLEID is nullable. DOC-3) Modify the section on SYSSEQUENCES to state that users should not bother querying the CURRENTVALUE column. Instead, they should use syscs_peek_at_sequence() to peek at the instantaneous current value of a sequence generator. This patch will require a release note explaining that users should use syscs_peek_at_sequence() rather than SYSSEQUENCES.CURRENTVALUE. Touches the following files: -- M java/engine/org/apache/derby/iapi/services/io/RegisteredFormatIds.java M java/engine/org/apache/derby/iapi/services/io/StoredFormatIds.java A java/engine/org/apache/derby/iapi/sql/dictionary/SequenceState.java New Formatable to hold the end of pre-allocation ranges. -- M java/engine/org/apache/derby/iapi/sql/dictionary/DataDescriptorGenerator.java A java/engine/org/apache/derby/iapi/sql/dictionary/GhostDescriptor.java New tuple describing a row in SYSGHOST. -- M java/engine/org/apache/derby/iapi/sql/dictionary/CatalogRowFactory.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/sql/catalog/SYSCONGLOMERATESRowFactory.java M java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java Support for creating SYSGHOST and deleting orphans. -- M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java A
[jira] [Updated] (DERBY-5495) Master issue to track fixes to sequence generators
[ https://issues.apache.org/jira/browse/DERBY-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5495: - Urgency: Blocker (was: Normal) Bumping the urgency of this issue to clarify that these problems are a blocker for 10.9. Master issue to track fixes to sequence generators -- Key: DERBY-5495 URL: https://issues.apache.org/jira/browse/DERBY-5495 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Labels: derby_triage10_9 This is a master issue to which we can link issues with sequence/identity generators. -- 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
[jira] [Updated] (DERBY-5629) Queries with guarded null Parameter fail
[ https://issues.apache.org/jira/browse/DERBY-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5629: - Urgency: Normal (was: Urgent) Hi Bernard, Looking at Kristian, Knut, and Dag's comments, I get the impression that this is not legal syntax in the Standard dialect which Derby supports. The fix would be for Hibernate to generate ANSI/ISO Standard syntax when the datastore is Derby. I have lowered the urgency of this issue. The Urgency field is owned by the release manager. It reflects the release manager's judgment about the issues which gate the next release. You are welcome to adjust the Priority field to reflect how important this issue is to you. Thanks, -Rick Queries with guarded null Parameter fail Key: DERBY-5629 URL: https://issues.apache.org/jira/browse/DERBY-5629 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.8.2.2 Environment: java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing) Reporter: Bernard Labels: derby_triage10_9 Attachments: NullParameterHibernateDerbyMaven.zip, NullParameterHibernateHsqlMaven.zip Some test cases in the attached Maven project fail where a null parameter is passed in or a null value is coded in the query. In the context of this issue, a recently closed issue appears to be relevant: Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 Some test cases in the attached project are Hibernate JPQL cases where Hibernate takes care of generating the SQL queries. I thought it was appropriate to make a few cases not only one so that the issue gets a little more test coverage. I also assume that issue DERBY-1938 aims to fix what we can see in these cases. This has become a major issue because it causes failure of a minimalistic JPQL query as shown at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples that shows a JPQL query: SELECT a FROM Author a WHERE :lastName IS NULL OR LOWER(a.lastName) = :lastName -- 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
[jira] [Updated] (DERBY-5522) Document the NATIVE authentication scheme.
[ https://issues.apache.org/jira/browse/DERBY-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5522: - Attachment: NativeAuthenticationExample.java Hi Kim, I am attaching NativeAuthenticationExample.java. This is a single program which can be run embedded or client/server (see the header comment for how to run it). I recommend this as a replacement for the Dev Guide code examples which show how to turn on NATIVE authentication and work with SQL authorization. Thanks. Document the NATIVE authentication scheme. -- Key: DERBY-5522 URL: https://issues.apache.org/jira/browse/DERBY-5522 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase Attachments: CreateNativeUsers.java, CreateNativeUsers.java, DERBY-5522-devguide.diff, DERBY-5522-devguide.stat, DERBY-5522-devguide.zip, NativeAuthExampleClient1.java, NativeAuthExampleClient2.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthenticationExample.java, UseNativeUsers.java, UseNativeUsers.java We should document NATIVE authentication after we have implemented the changes described on DERBY-866. The documentation changes are described by the functional spec UserManagement.html attached to that issue. -- 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
[jira] [Updated] (DERBY-5522) Document the NATIVE authentication scheme.
[ https://issues.apache.org/jira/browse/DERBY-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5522: - Attachment: NativeAuthenticationExample.java Hi Kim, I'm attaching a new version of the program. The instructions for running the client/server version are simpler now. The program takes responsibility for bringing the server up and down. Hope this works better, -Rick Document the NATIVE authentication scheme. -- Key: DERBY-5522 URL: https://issues.apache.org/jira/browse/DERBY-5522 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase Attachments: CreateNativeUsers.java, CreateNativeUsers.java, DERBY-5522-devguide.diff, DERBY-5522-devguide.stat, DERBY-5522-devguide.zip, DERBY-5522-ref.diff, DERBY-5522-ref.stat, DERBY-5522-ref.zip, NativeAuthExampleClient1.java, NativeAuthExampleClient2.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthenticationExample.java, NativeAuthenticationExample.java, NativeAuthenticationExample.java, UseNativeUsers.java, UseNativeUsers.java We should document NATIVE authentication after we have implemented the changes described on DERBY-866. The documentation changes are described by the functional spec UserManagement.html attached to that issue. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-22-aa-dboFirst.diff Attaching derby-866-22-aa-dboFirst.diff. This patch addresses the edge case described above on 2012-03-19. Now the DBO must be the first user whose credentials are stored. Storing credentials for the DBO automatically marks the database as a credentials DB. Committed at subversion revision 1302868. Turning a legacy database into a credentials DB is now simpler. All you have to do is call syscs_create_user() to store the DBO's credentials. Regression tests passed cleanly for me. I also successfully ran NativeAuthenticationServiceTest on OJEC. Touches the following files: -- M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java M java/engine/org/apache/derby/catalog/SystemProcedures.java Make sure that the first credentials which are stored are those of the DBO. If they are, then set derby.authentication.provider=NATIVE::LOCAL in the database. That last piece of logic was moved out of the NATIVE authentication service into the syscs_create_user procedure. -- M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java New error message raised if you try to store credentials for some other user before you store the DBO's credentials. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast_init.sql M java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast1.jar This is the script which creates the jar files used by NativeAuthenticationServiceTest. The script was changed so that it no longer explicitly sets derby.authentication.provider=NATIVE::LOCAL in the database (not needed anymore). In addition, I turned off password expiration in the jar'd databases so that NativeAuthenticationServiceTest won't fail 32 days after checking in new jar'd databases. -- D java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java NativeAuthProcs was failing to shutdown correctly because user creation now turns on NATIVE+LOCAL authentication. This test is largely redundant--except for the password hashing tests, all of its cases are also tested in NativeAuthenticationServiceTest now. The password hashing tests were moved to NativeAuthenticationServiceTest and NativeAuthProcs was deprecated. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java This test needed lots of little tweaks to handle the new behavior. -- M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java Now the upgrade tests have to be careful to not actually store the DBO's credentials since that will turn on NATIVE+LOCAL authentication. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff, derby-866-22-aa-dboFirst.diff, dummyCredentials.properties, releaseNote.html
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching version 7 of the functional spec. This version describes the new behavior which was just checked in. Changes are summarized in the version 7.0 comment at the head of the spec: Introduced a new rule to simplify the conversion of legacy databases to NATIVE authentication and to make it harder to subvert a Credentials DB. The new rule is this: A database is a Credentials DB iff credentials have been stored in its SYS.SYSUSERS table. oClarified that derby.authentication.provider is set to the value NATIVE::LOCAL by Derby itself and that this value is never explicitly set by an application. oClarified that a legacy database becomes a Credentials DB when the DBO stores her credentials in SYS.SYSUSERS. Revised the example in the Database Creation section accordingly. Repeated this clarification in the section on Hard Upgrade. oClarified that the DBO's credentials must be the very first credentials stored in a legacy database via the syscs_util.syscs_create_user procedure. Calling this procedure permanently marks a database as a Credentials DB. In addition, clarified that when NATIVE authentication is enabled, Derby behaves as if derby.connection.requireAuthentication=true and derby.database.sqlAuthorization=true regardless of how those properties are set by any other means. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff, derby-866-22-aa-dboFirst.diff, dummyCredentials.properties, releaseNote.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-23-aa-improveErrorMessages.diff Attaching derby-866-23-aa-improveErrorMessages.diff. This patch improves the wording of some error messages, based on Kim's advice. Committed at subversion revision 1303069. Touches the following file: M java/engine/org/apache/derby/loc/messages.xml Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff, derby-866-22-aa-dboFirst.diff, derby-866-23-aa-improveErrorMessages.diff, dummyCredentials.properties, releaseNote.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-5659) Database corrupted after delete operation - results in sqlcode XSDB2
[ https://issues.apache.org/jira/browse/DERBY-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5659: - Urgency: Normal (was: Urgent) Resetting the urgency of this issue to normal. The urgency field is owned by the Derby release manager; it reflects the release manager's judgement about whether the issue gates producing a release. The priority field is the field which reflects the judgement of the reporter about how serious the issue is. Database corrupted after delete operation - results in sqlcode XSDB2 Key: DERBY-5659 URL: https://issues.apache.org/jira/browse/DERBY-5659 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.6.1.0 Environment: Windows 7 32 bit Reporter: ratish ram Priority: Critical Labels: corruption, xsdb2 Attachments: derby.log Derby Embedded Database became non-accessible after a delete operation. Trying to connect to the database now results in the following exception. Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ040, SQLERRMC: Failed to start database '' with class loader org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@73983ad7, see the next exception for details.::SQLSTATE: XSDB2Unknown container format at container null : 1,702,392,933 at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source) at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source) at org.apache.derby.client.net.NetConnection.init(Unknown Source) at org.apache.derby.client.net.NetConnection40.init(Unknown Source) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown Source) ... 52 more -- 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
[jira] [Updated] (DERBY-5659) Database corrupted after delete operation - results in sqlcode XSDB2
[ https://issues.apache.org/jira/browse/DERBY-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5659: - Urgency: Normal (was: Urgent) Database corrupted after delete operation - results in sqlcode XSDB2 Key: DERBY-5659 URL: https://issues.apache.org/jira/browse/DERBY-5659 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.6.1.0 Environment: Windows 7 32 bit Reporter: ratish ram Priority: Critical Labels: corruption, xsdb2 Derby Embedded Database became non-accessible after a delete operation. Trying to connect to the database now results in the following exception. Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ040, SQLERRMC: Failed to start database '' with class loader org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@73983ad7, see the next exception for details.::SQLSTATE: XSDB2Unknown container format at container null : 1,702,392,933 at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source) at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source) at org.apache.derby.client.net.NetConnection.init(Unknown Source) at org.apache.derby.client.net.NetConnection40.init(Unknown Source) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown Source) ... 52 more -- 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
[jira] [Updated] (DERBY-5658) Regularize capitalization in error messages for NATIVE authentication
[ https://issues.apache.org/jira/browse/DERBY-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5658: - Attachment: derby-5658-01-aa-fixCapitalization.diff Attaching derby-5658-01-aa-fixCapitalization.diff. This patch makes the casing of SYSCS_UTIL.SYSCS_CREATE_USER agree across the NATIVE authentication error messages. Committed at subversion revision 1301010. Touches the following file: M java/engine/org/apache/derby/loc/messages.xml Regularize capitalization in error messages for NATIVE authentication - Key: DERBY-5658 URL: https://issues.apache.org/jira/browse/DERBY-5658 Project: Derby Issue Type: Improvement Components: Miscellaneous Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Priority: Minor Attachments: derby-5658-01-aa-fixCapitalization.diff The 2012-03-14 comment on DERBY-866 notes some cases where capitalization is inconsistent. -- 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
[jira] [Updated] (DERBY-5657) Message XCY05 for NATIVE authentication is (too?) complex
[ https://issues.apache.org/jira/browse/DERBY-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5657: - Attachment: derby-5657-01-aa-splitMessage.diff Attaching derby-5657-01-aa-splitMessage.diff. This patch splits the complex message into 3 simpler messages. Committed at subversion revision 1301064. Message XCY05 for NATIVE authentication is (too?) complex - Key: DERBY-5657 URL: https://issues.apache.org/jira/browse/DERBY-5657 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Priority: Minor Fix For: 10.9.0.0 Attachments: derby-5657-01-aa-splitMessage.diff The error message XCY05 is rather complex: Invalid change of the derby.authentication.provider property. Once set to NATIVE authentication, this property cannot be changed. NATIVE::LOCAL is the only NATIVE value accepted by derby.authentication.provider. This property cannot be set to NATIVE::LOCAL unless credentials for the database owner have been stored in the database using the syscs_util.syscs_create_user procedure. I'd be in favor of simplifying this error message if possible, especially raising a more specific message for the error condition when the DBO hasn't been added as a user. Further, it was not clear to me that the information about derby.authentication.provider applies when setting it as a database property only. Is this message trying to describe three problem scenarios? a) Turning off NATIVE authentication is forbidden. b) Specifying an invalid value for derby.authentication.provider when set as a database property. c) Missing credentials for the DBO. -- 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
[jira] [Updated] (DERBY-5644) Typo in error message for NATIVE authentication
[ https://issues.apache.org/jira/browse/DERBY-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5644: - Attachment: derby-5644-01-aa-fixTypo.diff Attaching derby-5644-01-aa-fixTypo.diff. This patch fixes the typo. Committed at subversion revision 1300090. Typo in error message for NATIVE authentication --- Key: DERBY-5644 URL: https://issues.apache.org/jira/browse/DERBY-5644 Project: Derby Issue Type: Improvement Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Priority: Minor Attachments: derby-5644-01-aa-fixTypo.diff The word No-one should be changed to No one in message 4251E. The current text is: No-one can view the 'SYSUSERS'.'PASSWORD' column. -- 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
[jira] [Updated] (DERBY-5644) Typo in error message for NATIVE authentication
[ https://issues.apache.org/jira/browse/DERBY-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5644: - Fix Version/s: 10.9.0.0 Typo in error message for NATIVE authentication --- Key: DERBY-5644 URL: https://issues.apache.org/jira/browse/DERBY-5644 Project: Derby Issue Type: Improvement Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Priority: Minor Fix For: 10.9.0.0 Attachments: derby-5644-01-aa-fixTypo.diff The word No-one should be changed to No one in message 4251E. The current text is: No-one can view the 'SYSUSERS'.'PASSWORD' column. -- 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
[jira] [Updated] (DERBY-5650) ERROR XSDBB: Unknown page format at page Page(1936,Container(0, 1009)), page dump follows: Hex dump: 00000000:
[ https://issues.apache.org/jira/browse/DERBY-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5650: - Urgency: Urgent (was: Blocker) Bug behavior facts: Data corruption,Seen in production ERROR XSDBB: Unknown page format at page Page(1936,Container(0, 1009)), page dump follows: Hex dump: : -- Key: DERBY-5650 URL: https://issues.apache.org/jira/browse/DERBY-5650 Project: Derby Issue Type: Bug Affects Versions: 10.6.1.0 Reporter: Deepika Kochhar i am trying to insert values into the database table EVENTS_TABLE where i have 18 columns with EVENT_ID as Unique but can be null. Indexes for this table is EVENT_INDEX which points to EVENT_ID internally. Now at some point of insertion into this Table, i am getting The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'EVENT_INDEX' defined on 'EVENTS_TABLE'. error in my logs and in derby logs i am getting ERROR XSDBB: Unknown page format at page Page(1936,Container(0, 1009)), page dump follows: Hex dump: : error. Please let me know why this is happening and what is the meaning of this error. -- 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
[jira] [Updated] (DERBY-5647) NATIVE warns about password expiry for DBO
[
https://issues.apache.org/jira/browse/DERBY-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5647:
-
Attachment: derby-5647-01-aa-staleDBOpassword.diff
Attaching derby-5647-01-aa-staleDBOpassword.diff. This patch adds a new warning
message for the expiration of the DBO's password, as Knut and Kristian advised.
Committed at subversion revision 1300120.
I'm not clear on whether we should write password expiration warnings to
derby.log. As Kristian notes, this could just turn into spam. In addition, I
would feel more comfortable about writing this kind of information to a
security audit log rather than to the general diagnostic log (and we don't have
a separate security audit log yet).
Touches the following files:
M
java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java
NATIVE warns about password expiry for DBO
--
Key: DERBY-5647
URL: https://issues.apache.org/jira/browse/DERBY-5647
Project: Derby
Issue Type: Bug
Components: Services
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Priority: Minor
Attachments: derby-5647-01-aa-staleDBOpassword.diff
The DBO's password cannot expire. Still, NATIVE warns that the password is
about to expire.
ij connect 'jdbc:derby:authdb;create=true;user=admin';
ij call
syscs_util.syscs_set_database_property('derby.authentication.native.passwordLifetimeMillis',
'100');
0 rows inserted/updated/deleted
ij call syscs_util.syscs_create_user('ADMIN', '%*$');
0 rows inserted/updated/deleted
ij call
syscs_util.syscs_set_database_property('derby.authentication.provider',
'NATIVE::LOCAL');
0 rows inserted/updated/deleted
ij connect 'jdbc:derby:authdb;shutdown=true';
ERROR 08006: Database 'authdb' shutdown.
ij connect 'jdbc:derby:authdb;user=admin;password=%*$';
WARNING 01J15: Your password will expire in 0 day(s). Please use the
SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password.
--
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
[jira] [Updated] (DERBY-5648) Unclear password expiry warning when using separate credentials db
[
https://issues.apache.org/jira/browse/DERBY-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5648:
-
Attachment: derby-5648-01-aa-missingUser.diff
Attaching derby-5648-01-aa-missingUser.diff. This patch adds the database name
to the password expiration messages. This patch also raises an error if you try
to drop a user who doesn't exist or if you try to change the password of a
missing user. I am running regression tests now.
Touches the following files:
M java/engine/org/apache/derby/iapi/error/SQLWarningFactory.java
M
java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
New message and 2 changed messages. Added a factory method for 2-arg warnings.
M java/engine/org/apache/derby/catalog/SystemProcedures.java
Checks for whether user exists.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java
Test cases.
Unclear password expiry warning when using separate credentials db
--
Key: DERBY-5648
URL: https://issues.apache.org/jira/browse/DERBY-5648
Project: Derby
Issue Type: Improvement
Components: Services
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Priority: Minor
Attachments: derby-5648-01-aa-missingUser.diff
If you log on to a database (other than the credentials db) and your password
is about to expire, you'll be advised to change your password using the
SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure. However, the warning message does
not say you need to log on to the credentials db to change your password.
This may lead the user to modify the password in the current database instead
of the credentials database, thinking everything is well.
ij(CONNECTION1) connect 'jdbc:derby:otherdb;user=test;password=abc';
WARNING 01J15: Your password will expire in 0 day(s). Please use the
SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password.
ij(CONNECTION2) CALL SYSCS_UTIL.SYSCS_MODIFY_PASSWORD('new-password');
0 rows inserted/updated/deleted
ij(CONNECTION2) connect 'jdbc:derby:otherdb;user=test;password=new-password';
ERROR 08004: Connection authentication failure occurred. Reason: Invalid
authentication..
Even though SYSCS_MODIFY_PASSWORD succeeds, the password has not been updated
in the credentials db.
--
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
[jira] [Updated] (DERBY-5648) Unclear password expiry warning when using separate credentials db
[
https://issues.apache.org/jira/browse/DERBY-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5648:
-
Attachment: derby-5648-01-ab-missingUser.diff
Attaching derby-5648-01-ab-missingUser.diff. This patch removes a 10.9 upgrade
test case which fails now that syscs_modify_password() raises the new error.
Other than the upgrade failure, the tests ran cleanly for me. Committed at
subversion revision 1300248.
Touches the following additional file:
M
java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java
Unclear password expiry warning when using separate credentials db
--
Key: DERBY-5648
URL: https://issues.apache.org/jira/browse/DERBY-5648
Project: Derby
Issue Type: Improvement
Components: Services
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Priority: Minor
Attachments: derby-5648-01-aa-missingUser.diff,
derby-5648-01-ab-missingUser.diff
If you log on to a database (other than the credentials db) and your password
is about to expire, you'll be advised to change your password using the
SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure. However, the warning message does
not say you need to log on to the credentials db to change your password.
This may lead the user to modify the password in the current database instead
of the credentials database, thinking everything is well.
ij(CONNECTION1) connect 'jdbc:derby:otherdb;user=test;password=abc';
WARNING 01J15: Your password will expire in 0 day(s). Please use the
SYSCS_UTIL.SYSCS_MODIFY_PASSWORD procedure to change your password.
ij(CONNECTION2) CALL SYSCS_UTIL.SYSCS_MODIFY_PASSWORD('new-password');
0 rows inserted/updated/deleted
ij(CONNECTION2) connect 'jdbc:derby:otherdb;user=test;password=new-password';
ERROR 08004: Connection authentication failure occurred. Reason: Invalid
authentication..
Even though SYSCS_MODIFY_PASSWORD succeeds, the password has not been updated
in the credentials db.
--
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
[jira] [Updated] (DERBY-5644) Typo in error message for NATIVE authentication
[ https://issues.apache.org/jira/browse/DERBY-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5644: - Summary: Typo in error message for NATIVE authentication (was: Type in error message for NATIVE authentication) Typo in error message for NATIVE authentication --- Key: DERBY-5644 URL: https://issues.apache.org/jira/browse/DERBY-5644 Project: Derby Issue Type: Improvement Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Priority: Minor The word No-one should be changed to No one in message 4251E. The current text is: No-one can view the 'SYSUSERS'.'PASSWORD' column. -- 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
[jira] [Updated] (DERBY-5443) reduce number of times sequence updater does it work on user thread rather than nested user thread.
[ https://issues.apache.org/jira/browse/DERBY-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5443: - Attachment: blockingDDL.sql reduce number of times sequence updater does it work on user thread rather than nested user thread. --- Key: DERBY-5443 URL: https://issues.apache.org/jira/browse/DERBY-5443 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.9.0.0 Reporter: Mike Matrigali Priority: Minor Attachments: blockingDDL.sql Currently the Sequence updater tries to do the system catalog update as part of the user thread, but in a nested user transaction. When this works all is well as the nested user transaction is immediately committed and thus the throughput of all threads depending on allocating sequences is optimized. In order to be able to commit the nested writable transaction independently the lock manager must treat the parent and nested transactions as two independent transactions and locks held by the parent will thus block the child. And in effect any lock that is blocked by the parent is a deadlock, but the lock manager does not understand this relationship and thus only will timeout and not recognize the implicit deadlock. Only 2 cases come to mind of the parent blocking the child in this manner for sequences: 1) ddl like create done in transaction followed by inserts into the table requiring sequence update. 2) users doing jdbc data dictionary lookups in a multistatment transaction resulting in holding locks on the system catalog rows and subsequently doing inserts into the table requiring sequence updates. The sequence updater currently never waits for a lock in the nested transaction and assumes any blocked lock is this parent deadlock case. It then falls back on doing the update in tranaction and then the system catalog lock remains until the user transaction commits which could then hold hostage all other inserts into the table. This is ok in the above 2 cases as there is not any other choice since the user transaction is already holding the system hostage. The problem is the case where it was not a deadlock but just another thread trying to do the sequence update. In this case the thread should not be getting locks on the user thread. I am not sure best way to address this project but here are some ideas: 1) enhance lock manager to recognize the deadlock and then change to code to somehow do an immediately deadlock check for internal nested transactions, no matter what the system default is. Then the code should go ahead and use the system wait timeout on this lock and only fall over to using user transaction for deadlock (or maybe even throw a new self deadlock error that would only be possible for internal transactions). 2) somehow execute the internal system catalog update as part of a whole different transaction in the system. Would need a separate context. Sort of like the background daemon threads. Then no self deadlock is possible and it could just go ahead and wait. The downside is that then the code to wait for a new sequence becomes more complicated as it has to wait for an event from another thread. But seems like it could designed with locks/synchonization blocks somehow. 3) maybe add another lock synchronization that would only involve threads updating the sequences. So first an updater would request the sequence updater lock (with a key specific to the table and a new type) and it could just wait on it. It should never be held by parent transaction. Then it would still need the catalog row lock to do the update. I think with proper ordering this would insure that blocking on the catalog row lock would only happen in the self deadlock case. Overall this problem is less important as the size of the chunk of sequence is tuned properly for the application, and ultimately best if derby autotuned the chunk. There is a separate jira for auto tuning: DERBY-5295 -- 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
[jira] [Updated] (DERBY-3670) Add spatial datatypes to Derby
[ https://issues.apache.org/jira/browse/DERBY-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3670: - Description: This issue is a place to track work being done on adding spatial datatypes to Derby. See, for instance, these email threads: http://www.nabble.com/Spatial-Functionality-td17042147.html#a17042147 http://www.nabble.com/Spatial-extensions-for-Derby-td17119485.html#a17119485 In this thread, David Smiley announces an Apache-licensed package of spatial datatypes and functions: http://old.nabble.com/Are-devs-interested-in-adding-spatial-support-%28Spatial4j%29--to33448923.html#a33448923 was: This issue is a place to track work being done on adding spatial datatypes to Derby. See, for instance, these email threads: http://www.nabble.com/Spatial-Functionality-td17042147.html#a17042147 http://www.nabble.com/Spatial-extensions-for-Derby-td17119485.html#a17119485 Add spatial datatypes to Derby -- Key: DERBY-3670 URL: https://issues.apache.org/jira/browse/DERBY-3670 Project: Derby Issue Type: Improvement Components: SQL, Store Reporter: Rick Hillegas This issue is a place to track work being done on adding spatial datatypes to Derby. See, for instance, these email threads: http://www.nabble.com/Spatial-Functionality-td17042147.html#a17042147 http://www.nabble.com/Spatial-extensions-for-Derby-td17119485.html#a17119485 In this thread, David Smiley announces an Apache-licensed package of spatial datatypes and functions: http://old.nabble.com/Are-devs-interested-in-adding-spatial-support-%28Spatial4j%29--to33448923.html#a33448923 -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-21-aa-emptyCredentials.diff Attaching derby-866-21-aa-emptyCredentials.diff. This patch adds logic to prevent the creation of a credentials db with vacuous username or password. Null and are not allowed as the username or password. I am running the full regression tests now. I have successfully run NativeAuthenticationServiceTest on the following platforms: 1) Java 6 on Mac OSX 2) Java 6 on XP 3) Java 5 on XP 4) OJEC Touches the following files: -- M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java The new check for empty credentials. -- M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java A new error message. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java Some tests for this case. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, derby-866-21-aa-emptyCredentials.diff, dummyCredentials.properties, releaseNote.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-21-ab-emptyCredentials.diff Attaching derby-866-21-ab-emptyCredentials.diff. This patch adjusts ErrorCodeTest to account for the new error message. My regression test run also tripped over a series of NPEs in SecurityManagerSetup.getEffectivePolicyResource(). Those errors went away when I resynced with the head of trunk. I will re-run the full regression tests. This patch touches the same files as the previous rev plus: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/ErrorCodeTest.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff, dummyCredentials.properties, releaseNote.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: releaseNote.html Attaching first rev of a release note for this feature. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, dummyCredentials.properties, releaseNote.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-5632) Logical deadlock happened when freezing/unfreezing the database
[ https://issues.apache.org/jira/browse/DERBY-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5632: - Bug behavior facts: Seen in production (was: Seen in production,Crash) Unchecking the 'crash' box. There is probably room for improvement here, if only in the documentation. Logical deadlock happened when freezing/unfreezing the database --- Key: DERBY-5632 URL: https://issues.apache.org/jira/browse/DERBY-5632 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.2.2 Environment: Oracle M3000/Solaris 10 Reporter: Brett Bergquist Attachments: stack.txt Tried to make a quick database backup by freezing the database, performing a ZFS snapshot, and then unfreezing the database. The database was frozen but then a connection to the database could not be established to unfreeze the database. Looking at the stack trace of the network server, , I see 3 threads that are trying to process a connection request. Each of these is waiting on: at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown Source) - waiting to lock 0xfffd3a7fcc68 (a org.apache.derby.impl.services.cache.ConcurrentCache) That object is owned by: - locked 0xfffd3a7fcc68 (a org.apache.derby.impl.services.cache.ConcurrentCache) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openGroupFetchScan(Unknown Source) at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.updateIndexStatsMinion(Unknown Source) at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.runExplicitly(Unknown Source) at org.apache.derby.impl.sql.execute.AlterTableConstantAction.updateStatistics(Unknown Source) which itself is waiting for the object: at java.lang.Object.wait(Native Method) - waiting on 0xfffd3ac1d608 (a org.apache.derby.impl.store.raw.log.LogToFile) at java.lang.Object.wait(Object.java:485) at org.apache.derby.impl.store.raw.log.LogToFile.flush(Unknown Source) - locked 0xfffd3ac1d608 (a org.apache.derby.impl.store.raw.log.LogToFile) at org.apache.derby.impl.store.raw.log.LogToFile.flush(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.flush(Unknown Source) So basically what I think is happening is that the database is frozen, the statistics are being updated on another thread which has the org.apache.derby.impl.services.cache.ConcurrentCache locked and then waits for the LogToFile lock and the connecting threads are waiting to lock org.apache.derby.impl.services.cache.ConcurrentCache to connect and these are where the database is going to be unfrozen.Not a deadlock as far as the JVM is concerned but it will never leave this state either. -- 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
[jira] [Updated] (DERBY-5576) derby can't start or open in applet on safari 5.1.2
[ https://issues.apache.org/jira/browse/DERBY-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5576: - Bug behavior facts: (was: Crash) Unchecking the 'crash' box. I don't see any evidence so far to suggest that this is a Derby crash. derby can't start or open in applet on safari 5.1.2 --- Key: DERBY-5576 URL: https://issues.apache.org/jira/browse/DERBY-5576 Project: Derby Issue Type: Bug Components: Services Affects Versions: 10.8.2.2 Environment: java 1.6.0_u30 or 1.7.0_u2 windowns xp sp3 or windows 7 sp1 safari 5.1.2 derby 10.8.2.2(derby.jar, derbyclient.jar, derbynet.jar) IE work fine but safari error. Reporter: moonumi Priority: Critical Labels: applet, derby, safari XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams ERROR XBM02: XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-20-aa-npeAndUserProbing.diff Attaching derby-866-20-aa-npeAndUserProbing.diff. This patch addresses Knut's recent suggestions: A) Now we perform a dummy password hash if the user doesn't exist. This is meant to confuse blackhats who probe for legal usernames by measuring how long password evaluation takes. B) Some defensive logic was added to prevent some NPEs. Note that I'm not sure that the NPEs could really happen. My attempt to trigger them resulted in tripping across an earlier NPE. I've plugged that one too. The defensive logic seems like a good idea, nonetheless. I have successfully run NativeAuthenticationServiceTest on the following platforms: 1) Java 6 on Mac OSX 2) Java 6 on XP 3) Java 5 on XP 4) OJEC I am running full regression tests now. Touches the following files: - M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java Addressed (A) and (B). - M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java Added a test for the NPE which was fixed. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-20-ab-npeAndUserProbing.diff Tests passed cleanly for me. Attaching derby-866-20-ab-npeAndUserProbing.diff. This version uses AuthenticationServiceBase.getDatabaseProperties() as Knut suggested. Committed at subversion revision 1295189. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, derby-866-20-ab-npeAndUserProbing.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-5587) Due to licensing issues, fix or remove the monohtml docs posted on Derby's documentation page.
[ https://issues.apache.org/jira/browse/DERBY-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5587: - Urgency: Normal (was: Blocker) Hi Myrna, You may be right, but I am not a lawyer. In any event, I have reduced the urgency of this issue. As long as we address DERBY-5586 (removing the xsl script from the repository and disabling future generation of monohtml), then I do not see this issue being a blocker. Let's leave this issue open for a little while longer to let other people add their opinions. If no-one objects to your proposal, then I would be ok with closing this issue in a while. Thanks. Due to licensing issues, fix or remove the monohtml docs posted on Derby's documentation page. -- Key: DERBY-5587 URL: https://issues.apache.org/jira/browse/DERBY-5587 Project: Derby Issue Type: Bug Components: Web Site Affects Versions: 10.9.0.0 Reporter: Rick Hillegas The monohtml versions of Derby's docs (from 10.3 onwards) need a legal notice. We should either add that notice to the monohtml docs or we should remove them from the Derby website. This issue is discussed in the following derby-dev email thread: http://old.nabble.com/Copyright-clairification-for-fo2html.xsl-in-Derby-software.-to33087407.html#a33087407 -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-19-aa-replicationTest.diff Attaching derby-866-19-aa-replicationTest.diff. This patch adds a test for replicating databases when NATIVE authentication is on. Most of the changes in this patch result from replacing copy/pasted code with calls to some common methods which create connection URLs and databases. The common methods add credentials when authentication is on. I have successfully run ReplicationSuite with this patch on the following platforms: 1) Java 6 on Mac OSX 2) Java 6 on XP 3) Java 5 on XP On the strength of those results, I have committed this patch at subversion revision 1294812. Touches the following files: - M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationSuite.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, derby-866-19-aa-replicationTest.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-5611) We don't provide any advice about what permissions are required to run ij under a Java security manager.
[ https://issues.apache.org/jira/browse/DERBY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5611: - Summary: We don't provide any advice about what permissions are required to run ij under a Java security manager. (was: Permissions granted by server.policy to derbytools.jar are not sufficient to run ij) Changed the title of this issue. I agree that we shouldn't expect the server policy file to be concerned with the permissions needed by Derby tools (leaving aside the question of sysinfo). I still think that we ought to figure out what permissions are needed by the Derby tools and we should document this so that people don't have to re-discover this information when they need it. Thanks. We don't provide any advice about what permissions are required to run ij under a Java security manager. Key: DERBY-5611 URL: https://issues.apache.org/jira/browse/DERBY-5611 Project: Derby Issue Type: Bug Components: Network Server, Tools Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Priority: Minor server.policy grants derbytools.jar the permission to read several system properties. However, at startup ij tries to read all of the system properties. This happens in ij.jj in the initFromEnvironment() method. To call System.getProperties(), you need the following permission: permission java.util.PropertyPermission *, read,write; ij startup fails with this error trace: Exception in thread main java.security.AccessControlException: access denied (java.util.PropertyPermission * read,write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPropertiesAccess(SecurityManager.java:1252) at java.lang.System.getProperties(System.java:581) at org.apache.derby.impl.tools.ij.ij$1.run(ij.java:113) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.tools.ij.ij.initFromEnvironment(ij.java:111) at org.apache.derby.impl.tools.ij.utilMain.initFromEnvironment(utilMain.java:175) at org.apache.derby.impl.tools.ij.Main.init(Main.java:244) at org.apache.derby.impl.tools.ij.Main.getMain(Main.java:196) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:59) Here are some ways to fix this problem: 1) Remove the whole block of permissions for derbytools.jar. Maybe those permissions don't belong in server.policy. Note that a similar block of permissions also appears in template.policy with a comment suggesting that they are sufficient for running the Derby tools. 2) Add to the derbytools block the missing permission. 3) Re-write initFromEnvironment() so that it reads only a few properties rather than all properties. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-17-aa-grantRevokeNative.diff Attaching derby-866-17-aa-grantRevokeNative.diff. This patch adds some more tests for granting/revoking EXECUTE permission on the NATIVE procs. Seemed useful to re-test this behavior with NATIVE authentication turned on. Committed at subversion revision 1245451. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching rev 6 of the functional spec. This rev clarifies a couple points: oClarify that if NATIVE authentication is set at the system level, it can still be overridden at the database level using database-only properties. oClarify that you must shutdown the network server before shutting down the Derby engine when you are using NATIVE authentication. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-18-aa-encryptedCredentialsDB.diff Attaching derby-866-18-aa-encryptedCredentialsDB. This patch adds tests for encrypted credentials databases. I need to run full regression tests. I have successfully run NativeAuthenticationServiceTest on the following platforms: 1) Java 6 on Mac OSX 2) Java 6 on XP 3) Java 5 on XP 4) OJEC Touches the following files: - M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java M java/testing/org/apache/derbyTesting/junit/DataSourceConnector.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/XADataSourceConnector.java M java/testing/org/apache/derbyTesting/junit/ConnectionPoolDataSourceConnector.java M java/testing/org/apache/derbyTesting/junit/Connector.java Added ability to create a test connection with arbitrary properties. - M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast_init.sql M java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast1.jar New test for encrypted credentials databases. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, derby-866-17-aa-grantRevokeNative.diff, derby-866-18-aa-encryptedCredentialsDB.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-16-aa-credDBViaSubprotocol.diff Attaching derby-866-16-aa-credDBViaSubprotocol.diff. This patch adds tests for system-wide authentication using a credentials db accessed via the jar and classpath subprotocols. The modified NativeAuthenticationServiceTest ran cleanly for me on the following platforms: 1) Java 6 on Mac OSX 2) Java 6 on XP 3) Java 5 on XP 4) OJEC Committed at subversion revision 1245126. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, derby-866-16-aa-credDBViaSubprotocol.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-5618) On Windows, orderly engine shutdown does not release the file handle on a jar file containing a database which was booted using the classpath subprotocol
[ https://issues.apache.org/jira/browse/DERBY-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5618: - Attachment: 5618.sql FileUtils.java Attaching a repro for this problem: 1) FileUtils.java - A set of routines to perform file operations. These operations are used by the following script. 2) 5618.sql - A script that shows the problem. Just compile FileUtils and put it on your classpath. Then run the script through ij. On Windows, orderly engine shutdown does not release the file handle on a jar file containing a database which was booted using the classpath subprotocol - Key: DERBY-5618 URL: https://issues.apache.org/jira/browse/DERBY-5618 Project: Derby Issue Type: Bug Components: Services, Store Affects Versions: 10.9.0.0 Environment: xp professional 5.1, oracle java 6, derby 10.9 trunk Reporter: Rick Hillegas Attachments: 5618.sql, FileUtils.java Boot a database in a jar file, using the classpath subprotocol, then shutdown the engine. This leaves the jar file still open on Windows. However, orderly engine shutdown correctly releases the file if you boot it using the jar subprotocol instead. I will attach a repro. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-15-ae-dbInJarFileOrOnClasspath.diff Attaching derby-866-15-ae-dbInJarFileOrOnClasspath.diff. This patch adds tests for booting databases which are protected by NATIVE/LOCAL authentication and which are reached via the jar and classpath subprotocols. I will run full regression tests. I have successfully run the patched NativeAuthenticationServiceTest on the following platforms: 1) Java 6 on Mac OSX 2) Java 6 on XP 3) Java 5 on XP 4) OJEC To test the subprotocols, I built a new jar file (nast1.jar) containing a test database. The jar file will be checked into the codeline. The patch includes a script and ant targets for regenerating this jar file. The following command regenerates nast1.jar: ant -quiet build-test-jars I think that we will have to regenerate this jar file when we create the 10.9 release candidate. That is because the jar file I am checking in now was created with an alpha version of Derby; I think that a production version of Derby will refuse to boot it. In testing against databases on the classpath, I tripped across a bug involving classpath databases and security managers: DERBY-5615. Currently, the classpath db test is run only when the security manager is disabled. Once DERBY-5615 is fixed, we should check to see whether we can re-enable the security manager for the classpath test in this patch. It may be that there are other bugs having to do with classpath dbs and the security manager. I also do not run the subprotocol tests on Windows platforms because of another bug I tripped across, having to do with releasing file handles during engine shutdown when databases have been booted from the classpath (DERBY-5618). When that bug is fixed, we can revisit NativeAuthenticationServiceTest. Touches the following files: -- M java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java DERBY-5615 tripped an NPE in this class. I put in some defensive logic. -- A java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast_init.sql M java/testing/org/apache/derbyTesting/functionTests/tests/lang/build.xml A java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast1.jar M build.xml Script and ant targets for building a database in a jar file. -- A java/testing/org/apache/derbyTesting/junit/ClasspathSetup.java M java/testing/org/apache/derbyTesting/junit/BaseTestCase.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/SupportFilesSetup.java M java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy Support for booting databases in jar files and on the classpath. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java The actual new test cases. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, derby-866-15-ae-dbInJarFileOrOnClasspath.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM
[jira] [Updated] (DERBY-5615) NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on
[ https://issues.apache.org/jira/browse/DERBY-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5615: - Issue fix info: Repro attached NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on Key: DERBY-5615 URL: https://issues.apache.org/jira/browse/DERBY-5615 Project: Derby Issue Type: Bug Components: SQL, Store Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: 5615.policy, 5615_bug.sql, 5615_init.sql, 5615_script I get an NPE trying to select from a table on which I don't have select privilege. The database is stored in a jar file accessed via the classpath protocol. BUILTIN authentication and sql authorization are turned on in the database. Running under a Java security manager. I will attach a repro. Here is the NPE: Failed Statement is: select * from KIWI.t java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:661) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:591) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1316) at org.apache.derby.impl.store.access.btree.OpenBTree.init(OpenBTree.java:380) at org.apache.derby.impl.store.access.btree.BTreeController.init(BTreeController.java:1250) at org.apache.derby.impl.store.access.btree.index.B2IController.init(B2IController.java:140) at org.apache.derby.impl.store.access.btree.index.B2I.open(B2I.java:821) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:476) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1308) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.debugGenerateInfo(DataDictionaryImpl.java:9584) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndexMinion(DataDictionaryImpl.java:9492) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:9303) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2887) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2851) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.finishTableDescriptor(DataDictionaryImpl.java:2408) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptorIndex1Scan(DataDictionaryImpl.java:2277) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTableDescriptor(DataDictionaryImpl.java:2293) at org.apache.derby.impl.sql.catalog.NameTDCacheable.setIdentity(NameTDCacheable.java:110) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(DataDictionaryImpl.java:2224) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.faultInTabInfo(DataDictionaryImpl.java:9905) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getNonCoreTI(DataDictionaryImpl.java:9702) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedPermissionsDescriptor(DataDictionaryImpl.java:13712) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTablePermsDescriptor(DataDictionaryImpl.java:13660) at org.apache.derby.impl.sql.catalog.PermissionsCacheable.setIdentity(PermissionsCacheable.java:71) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getPermissions(DataDictionaryImpl.java:13364) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTablePermissions(DataDictionaryImpl.java:13350) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.oneAuthHasPermissionOnTable(StatementTablePermission.java:239) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.hasPermissionOnTable(StatementTablePermission.java:160) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(StatementColumnPermission.java:99) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(GenericAuthorizer.java:183) at org.apache.derby.exe.ac40348015x0135x7cc7x4621x04070.fillResultSet(Unknown Source) at
[jira] [Updated] (DERBY-5615) NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on
[ https://issues.apache.org/jira/browse/DERBY-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5615: - Attachment: 5615_script 5615.policy 5615_init.sql 5615_bug.sql Attaching a repro for this bug: 1) 5615_script - Bash script to drive the repro. 2) 5615.policy - Java security policy used by the repro. 3) 5615_init.sql - IJ script to create the database. 4) 5615_bug.sql - IJ script to trigger the NPE. The header comment in the driving script explains how to run the repro. As you can see, the bug only appears if you run with a Java security manager. Without the security manager, the 5615_bug.sql script runs fine. NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on Key: DERBY-5615 URL: https://issues.apache.org/jira/browse/DERBY-5615 Project: Derby Issue Type: Bug Components: SQL, Store Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: 5615.policy, 5615_bug.sql, 5615_init.sql, 5615_script I get an NPE trying to select from a table on which I don't have select privilege. The database is stored in a jar file accessed via the classpath protocol. BUILTIN authentication and sql authorization are turned on in the database. Running under a Java security manager. I will attach a repro. Here is the NPE: Failed Statement is: select * from KIWI.t java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:661) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:591) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1316) at org.apache.derby.impl.store.access.btree.OpenBTree.init(OpenBTree.java:380) at org.apache.derby.impl.store.access.btree.BTreeController.init(BTreeController.java:1250) at org.apache.derby.impl.store.access.btree.index.B2IController.init(B2IController.java:140) at org.apache.derby.impl.store.access.btree.index.B2I.open(B2I.java:821) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:476) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1308) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.debugGenerateInfo(DataDictionaryImpl.java:9584) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndexMinion(DataDictionaryImpl.java:9492) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:9303) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2887) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2851) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.finishTableDescriptor(DataDictionaryImpl.java:2408) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptorIndex1Scan(DataDictionaryImpl.java:2277) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTableDescriptor(DataDictionaryImpl.java:2293) at org.apache.derby.impl.sql.catalog.NameTDCacheable.setIdentity(NameTDCacheable.java:110) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(DataDictionaryImpl.java:2224) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.faultInTabInfo(DataDictionaryImpl.java:9905) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getNonCoreTI(DataDictionaryImpl.java:9702) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedPermissionsDescriptor(DataDictionaryImpl.java:13712) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTablePermsDescriptor(DataDictionaryImpl.java:13660) at org.apache.derby.impl.sql.catalog.PermissionsCacheable.setIdentity(PermissionsCacheable.java:71) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getPermissions(DataDictionaryImpl.java:13364) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTablePermissions(DataDictionaryImpl.java:13350) at
[jira] [Updated] (DERBY-5615) NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on
[ https://issues.apache.org/jira/browse/DERBY-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5615: - Attachment: derby.log Attaching the full derby.log with the NPE. There's not a lot more information in there, though. Thanks. NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on Key: DERBY-5615 URL: https://issues.apache.org/jira/browse/DERBY-5615 Project: Derby Issue Type: Bug Components: SQL, Store Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: 5615.policy, 5615_bug.sql, 5615_init.sql, 5615_script, derby.log I get an NPE trying to select from a table on which I don't have select privilege. The database is stored in a jar file accessed via the classpath protocol. BUILTIN authentication and sql authorization are turned on in the database. Running under a Java security manager. I will attach a repro. Here is the NPE: Failed Statement is: select * from KIWI.t java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:661) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:591) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1316) at org.apache.derby.impl.store.access.btree.OpenBTree.init(OpenBTree.java:380) at org.apache.derby.impl.store.access.btree.BTreeController.init(BTreeController.java:1250) at org.apache.derby.impl.store.access.btree.index.B2IController.init(B2IController.java:140) at org.apache.derby.impl.store.access.btree.index.B2I.open(B2I.java:821) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:476) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1308) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.debugGenerateInfo(DataDictionaryImpl.java:9584) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndexMinion(DataDictionaryImpl.java:9492) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:9303) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2887) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2851) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.finishTableDescriptor(DataDictionaryImpl.java:2408) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptorIndex1Scan(DataDictionaryImpl.java:2277) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTableDescriptor(DataDictionaryImpl.java:2293) at org.apache.derby.impl.sql.catalog.NameTDCacheable.setIdentity(NameTDCacheable.java:110) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(DataDictionaryImpl.java:2224) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.faultInTabInfo(DataDictionaryImpl.java:9905) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getNonCoreTI(DataDictionaryImpl.java:9702) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedPermissionsDescriptor(DataDictionaryImpl.java:13712) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTablePermsDescriptor(DataDictionaryImpl.java:13660) at org.apache.derby.impl.sql.catalog.PermissionsCacheable.setIdentity(PermissionsCacheable.java:71) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getPermissions(DataDictionaryImpl.java:13364) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTablePermissions(DataDictionaryImpl.java:13350) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.oneAuthHasPermissionOnTable(StatementTablePermission.java:239) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.hasPermissionOnTable(StatementTablePermission.java:160) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(StatementColumnPermission.java:99) at org.apache.derby.impl.sql.conn.GenericAuthorizer.authorize(GenericAuthorizer.java:183) at
[jira] [Updated] (DERBY-5615) NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on
[ https://issues.apache.org/jira/browse/DERBY-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5615: - Attachment: derby.log Here's the log running with insane jars. The debug printing by the DataDictionary disappears and the DD trundles along into another NPE. NPE in Store when running SELECT in a read-only database accessed via the classpath subprotocol when authentication, authorization, and Java security are turned on Key: DERBY-5615 URL: https://issues.apache.org/jira/browse/DERBY-5615 Project: Derby Issue Type: Bug Components: SQL, Store Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: 5615.policy, 5615_bug.sql, 5615_init.sql, 5615_script, derby.log, derby.log I get an NPE trying to select from a table on which I don't have select privilege. The database is stored in a jar file accessed via the classpath protocol. BUILTIN authentication and sql authorization are turned on in the database. Running under a Java security manager. I will attach a repro. Here is the NPE: Failed Statement is: select * from KIWI.t java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:661) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:591) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1316) at org.apache.derby.impl.store.access.btree.OpenBTree.init(OpenBTree.java:380) at org.apache.derby.impl.store.access.btree.BTreeController.init(BTreeController.java:1250) at org.apache.derby.impl.store.access.btree.index.B2IController.init(B2IController.java:140) at org.apache.derby.impl.store.access.btree.index.B2I.open(B2I.java:821) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:476) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1308) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.debugGenerateInfo(DataDictionaryImpl.java:9584) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndexMinion(DataDictionaryImpl.java:9492) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:9303) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2887) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getColumnDescriptorsScan(DataDictionaryImpl.java:2851) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.finishTableDescriptor(DataDictionaryImpl.java:2408) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptorIndex1Scan(DataDictionaryImpl.java:2277) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTableDescriptor(DataDictionaryImpl.java:2293) at org.apache.derby.impl.sql.catalog.NameTDCacheable.setIdentity(NameTDCacheable.java:110) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTableDescriptor(DataDictionaryImpl.java:2224) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.faultInTabInfo(DataDictionaryImpl.java:9905) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getNonCoreTI(DataDictionaryImpl.java:9702) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedPermissionsDescriptor(DataDictionaryImpl.java:13712) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getUncachedTablePermsDescriptor(DataDictionaryImpl.java:13660) at org.apache.derby.impl.sql.catalog.PermissionsCacheable.setIdentity(PermissionsCacheable.java:71) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getPermissions(DataDictionaryImpl.java:13364) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTablePermissions(DataDictionaryImpl.java:13350) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.oneAuthHasPermissionOnTable(StatementTablePermission.java:239) at org.apache.derby.iapi.sql.dictionary.StatementTablePermission.hasPermissionOnTable(StatementTablePermission.java:160) at org.apache.derby.iapi.sql.dictionary.StatementColumnPermission.check(StatementColumnPermission.java:99) at
[jira] [Updated] (DERBY-5607) Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server
[ https://issues.apache.org/jira/browse/DERBY-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5607: - Attachment: NASTHang.java Attaching NASTHang.java. This short program demonstrates the problem. Make sure that you compile this program at bytecode level 1.5 or earlier so that you can run it on Java 5. Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server - Key: DERBY-5607 URL: https://issues.apache.org/jira/browse/DERBY-5607 Project: Derby Issue Type: Bug Components: Network Client, Network Server, Services Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: NASTHang.java A deadlock in the Java 5 VM hangs connection attempts if you are using NATIVE authentication with a client which runs in the same VM as the server. I will attach a test case which demonstrates this. This bug is implicated in the failures being discussed on https://issues.apache.org/jira/browse/DERBY-5601 and was disclosed by the discussion on this email thread: http://old.nabble.com/-URGENT--Critical-test-situation-on-trunk-to33259629.html#a33259629 The bug arises when NativeAuthenticationServiceImpl attempts a nested connection to the Credentials database during database creation. The nested connection is attempted in order to dertermine whether the user has system-wide privilege to create databases. -- 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
[jira] [Updated] (DERBY-5607) Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server
[ https://issues.apache.org/jira/browse/DERBY-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5607: - Issue fix info: Repro attached Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server - Key: DERBY-5607 URL: https://issues.apache.org/jira/browse/DERBY-5607 Project: Derby Issue Type: Bug Components: Network Client, Network Server, Services Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Attachments: NASTHang.java A deadlock in the Java 5 VM hangs connection attempts if you are using NATIVE authentication with a client which runs in the same VM as the server. I will attach a test case which demonstrates this. This bug is implicated in the failures being discussed on https://issues.apache.org/jira/browse/DERBY-5601 and was disclosed by the discussion on this email thread: http://old.nabble.com/-URGENT--Critical-test-situation-on-trunk-to33259629.html#a33259629 The bug arises when NativeAuthenticationServiceImpl attempts a nested connection to the Credentials database during database creation. The nested connection is attempted in order to dertermine whether the user has system-wide privilege to create databases. -- 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
[jira] [Updated] (DERBY-5607) Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server
[ https://issues.apache.org/jira/browse/DERBY-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5607: - Attachment: derby-5607-01-aa-userInternalDriver.diff Attaching derby-5607-01-aa-useInternalDriver.diff. This patch changes the way that the NATIVE authentication service opens a connection to Credentials DB when system-wide privileges need to be authenticated. Previously, the service called in through the Derby DataSources, which in turn called through the JDBC api. The deadlock occurred in that call through the JDBC api which happened inside the user's original JDBC call. That approach is replaced: now the NATIVE authentication service opens a connection to the Credentials DB using Derby's own InternalDriver, skipping the need for a nested call through JDBC. With this patch, the NASTHang test case now runs correctly on Java 5. I have run the NativeAuthenticationServiceTest successfully on the following platforms: 1) Java 6 on Mac OSX. 2) Java 5 on Linux. 3) CDC/FP 1.1 on OJEC. On the strength of those successful runs, I have committed this patch at subversion revision 1242105. Let's see if this fixes the nightly tests on the other Java 5 platforms. Touches the following file: M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java Deadlock in Java 5 VM when using NATIVE authentication with a client running in the same VM as the server - Key: DERBY-5607 URL: https://issues.apache.org/jira/browse/DERBY-5607 Project: Derby Issue Type: Bug Components: Network Client, Network Server, Services Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: NASTHang.java, derby-5607-01-aa-userInternalDriver.diff A deadlock in the Java 5 VM hangs connection attempts if you are using NATIVE authentication with a client which runs in the same VM as the server. I will attach a test case which demonstrates this. This bug is implicated in the failures being discussed on https://issues.apache.org/jira/browse/DERBY-5601 and was disclosed by the discussion on this email thread: http://old.nabble.com/-URGENT--Critical-test-situation-on-trunk-to33259629.html#a33259629 The bug arises when NativeAuthenticationServiceImpl attempts a nested connection to the Credentials database during database creation. The nested connection is attempted in order to dertermine whether the user has system-wide privilege to create databases. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-14-ac-badNativeSpec.diff Attaching derby-866-14-ad-badNativeSpec.diff. This patch adds some logic to prevent the authentication service from booting if the user specifies NATIVE + LOCAL authentication at the system level. The patch also adds more tests for setting and changing the value of the authentication provider property. The patch also re-enables this test for all platforms except Windows (see the discussion on DERBY-5601). The functional spec says that derby.authentication.provider=NATIVE::LOCAL is illegal if specified at the system level. That is because this setting does not identify a credentials DB for system-wide operations. This patch enforces that rule. If you attempt this setting at the system level, Derby will refuse to boot. Touches the following files: -- M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java Check for illegal system-wide setting of derby.authentication.provider=NATIVE::LOCAL. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java New tests for settings of derby.authentication.provider. -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java Re-enable NativeAuthenticationServiceTest on non-windows platforms. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, derby-866-14-ac-badNativeSpec.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-13-ab-systemWideOperationTests.diff Attaching derby-866-13-ab-systemWideOperationTests.diff. This adds an additional test to verify that NATIVE authentication operates correctly when restoring a database from a backup. The regression tests pass for me on this patch. The existing NATIVE authentication tests cover the following system-wide operations: 1) Database creation. 2) Engine shutdown. 3) Server shutdown. This is hard to see because the decorators wrap the default credentials. But I have traced the server code and verified that the NATIVE authenticator is being called at server shutdown and it is being passed the default credentials. This patch adds tests for database restoration. Touches the following files -- M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java The new test. I also reworked the decorators so that the fix for derby-5580 should not be needed anymore. Let me know if that bug resurfaces. -- M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java Removed a shutdown check added by a previous patch. It looks unnecessary to me. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, derby-866-13-ab-systemWideOperationTests.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-12-ac-passwordExpiration.diff Attaching derby-866-12-ac-passwordExpiration.diff. This patch adds password expiration. I am running the regression tests now. This patch adds 2 new Derby knobs: 1) derby.authentication.native.passwordLifetimeMillis - This is the maximum time (in milliseconds) that a NATIVE password remains valid. If more than this time has expired since a password was updated, then the user can't log in. A special check prevents the DBO's password from expiring. This property defaults to be 31 days. 2) derby.authentication.native.passwordLifetimeThreshold - This is the threshold (expressed as a double) for triggering a warning that a password is about to expire. This property defaults to be 0.125 (i.e. 1/8 the maximum password lifetime). This is a new property not described by the current functional spec. I will add a description to the spec. Touches the following files: M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java Adds a warning at connection time if a password is about to expire. Flunks authentication if the password has expired. M java/engine/org/apache/derby/impl/jdbc/authentication/AuthenticationServiceBase.java Adds logic to prevent the new properties from being set to bad values. M java/engine/org/apache/derby/iapi/reference/Property.java The new properties. M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java New error messages. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java New tests. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching rev 5 of the functional spec for this feature. This version makes the following changes: 1)Documents how the password hashing properties affect NATIVE passwords. 2)Documents that you CAN'T connect to un-upgraded databases when NATIVE authentication is on. 3)Changes the threshold for password-expiration warnings to be 1/8 the length of the maximum password lifetime. This can be configured via the derby.authentication.native.passwordLifetimeThreshold property. 4)Clarifies that the password of the DBO of a Credentials DB never expires. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, derby-866-12-ac-passwordExpiration.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-11-aa-upgradeTest.diff Attaching derby-866-11-aa-upgradeTest.diff. This patch adds a check to prevent you from trying to read a user's credentials in a database which hasn't been upgraded to 10.9, that is, a database which doesn't even have a SYSUSERS table. The patch adds another upgrade test to verify that you can't enable NATIVE LOCAL authentication in a soft-upgraded database. Committed at subversion revision 1236340. I have run the upgrade suite against the following starting versions: 10.1.3.1 10.2.2.1 10.3.3.0 10.4.2.1 10.5.3.0 10.6.2.1 10.7.1.1 10.8.2.2 Touches the following files: -- M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java Prevents code from calling DataDictionary.getUser() until the database has been hard-upgraded to 10.9. -- M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java New upgrade test. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-10-ac-propChanging.diff Attaching derby-866-10-ac-propChanging.diff. This patch adds logic to govern the on-disk setting of the derby.authentication.provider property. Tests passed cleanly for me. This patch makes the following changes: 1) Prevents an existing database from being set to NATIVE LOCAL authentication if the DBO's credentials haven't been stored. 2) Prevents derby.authentication.provider from being set on disk to any NATIVE value other than NATIVE::LOCAL. 3) Prevents NATIVE LOCAL authentication from being turned off or overridden once it has been turned on. 4) No longer sets derby.database.sqlAuthorization=true when creating a credentials DB. Instead, the database figures out whether SQL authorization is on based on whether derby.database.sqlAuthorization is set or NATIVE authentication is on. Touches the following files - M java/engine/org/apache/derby/iapi/services/property/PropertyUtil.java M java/engine/org/apache/derby/impl/jdbc/authentication/AuthenticationServiceBase.java If NATIVE authentication is set on-disk, then this trumps all other settings of derby.authentication.provider. - M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java Removes the transaction argument from DataDictionary.getUser(). The argument was not used. - M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java Don't set derby.database.sqlAuthorization on disk when creating a credentials DB. Instead, determine whether SQL authorization is on by consulting both derby.database.sqlAuthorization and derby.authentication.provider. - M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java New error message raised on bad attempts to set derby.authentication.provider on disk. - M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/DatabaseChangeSetup.java Logic to shutdown a single-use database as part of a test. - M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java New tests to verify the functionality added by this patch. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, derby-866-09-ad-nativeAuthenticationService.diff, derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, derby-866-10-ac-propChanging.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is
[jira] [Updated] (DERBY-5583) CTAS fails and returns erroneous error
[ https://issues.apache.org/jira/browse/DERBY-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5583: - Issue Type: Improvement (was: Bug) Reclassifying this issue as an enhancement request. CTAS fails and returns erroneous error -- Key: DERBY-5583 URL: https://issues.apache.org/jira/browse/DERBY-5583 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP, Netbeans 6.9.1, Was experiencing error with Derby 10.3.2.1 so upgraded to 10.8.2.2 ( latest ) and getting same error. ( Given description seems unlikely to be netbeans issue ) Reporter: Bob Power create table temp as select cid from tcopy; gives ; Error code -1, SQL state 42X01: Syntax error: Encountered EOF at line 5, column 5. running the select statement alone is fine ; select cid from tcopy; returns the data with no errors -- 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
[jira] [Updated] (DERBY-5577) Write a table function to expose the contents of SYSCONGLOMERATES.DESCRIPTOR
[ https://issues.apache.org/jira/browse/DERBY-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5577: - Attachment: IndexColumnVTI.java Attaching IndexColumnVTI.java. This table function cracks open SYSCONGLOMERATES.DESCRIPTOR. Before using the table function, you must register it: create function indexColumns() returns table ( conglomerateid char( 36 ), isUniqueboolean, isUniqueWithDuplicateNulls boolean, positionInIndex int, baseColumnPosition int, isColumnAscending boolean ) language java parameter style derby_jdbc_result_set reads sql data external name 'IndexColumnVTI.indexColumns'; Then you can join it with the Derby metadata. Here is a query which lists all of the columns in all of the indexes in the database: select t.tableName, cong.conglomerateName indexName, col.columnName, ic.positionInIndex from sys.systables t, sys.sysconglomerates cong, sys.syscolumns col, table( indexColumns() ) ic where t.tableID = cong.tableID and t.tableID = col.referenceID and cong.conglomerateID = ic.conglomerateID and ic.baseColumnPosition = col.columnNumber order by t.tableName, cong.conglomerateName, ic.positionInIndex; Write a table function to expose the contents of SYSCONGLOMERATES.DESCRIPTOR Key: DERBY-5577 URL: https://issues.apache.org/jira/browse/DERBY-5577 Project: Derby Issue Type: Improvement Components: Tools Reporter: Rick Hillegas Priority: Minor Attachments: IndexColumnVTI.java The Derby metadata does not make it easy to list out the columns in an index. We should write a table function which cracks open the IndexDescriptor stored in the SYSCONGLOMERATES table. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-09-ae-nativeAuthenticationServiceWithTests.diff Attaching derby-866-09-ae-nativeAuthenticationServiceWithTests.diff. This adds a first batch of tests to the previous rev of the patch. The new tests pass for me on my desktop and on a JSR169 platform. The full regression tests also passed for me except for an error in ErrorMessageTest. ErrorMessageTest ran fine for me standalone. The error may relate to recent work on DERBY-5564? Details at the end of this comment. The new tests stress the following configurations for both embedded and client/server: no authentication, NATIVE authentication, NATIVE+LOCAL authentication. That's a total of 6 configurations. Some test framework methods had to be changed to account for the fact that there's a new authentication failure message raised when the credentials db doesn't exist yet. Also SystemPropertyTestSetup now shuts down the engine BEFORE changing the properties, rather than vice-versa. Doing those operations in the original order fails if the property you are setting is the one which enables NATIVE authentication. This is because engine shutdown is an operation which must be authenticated and it can't be authenticated by the NATIVE machinery if the credentials database hasn't been created yet. Touches the following files in addition to the files touched by the previous rev of the patch: A java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java M java/testing/org/apache/derbyTesting/junit/BaseTestCase.java M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java M java/testing/org/apache/derbyTesting/junit/SystemPropertyTestSetup.java M java/testing/org/apache/derbyTesting/junit/DatabaseChangeSetup.java M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java M java/testing/org/apache/derbyTesting/junit/DropDatabaseSetup.java - Here is the error I saw in ErrorMessageTest: There was 1 failure: 1) testDeadlockTimeout(org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest)junit.framework.ComparisonFailure: Not a deadlock expected:40[00]1 but was:40[XL]1 at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:790) at org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest.testDeadlockTimeout(ErrorMessageTest.java:171) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116) 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 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested. The lockTable dump is: Wed Jan 18 11:51:46 PST 2012 XID |TYPE |MODE|LOCKCOUNT|LOCKNAME |STATE|TABLETYPE / LOCKOBJ |INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID | *** The following row is the victim *** 333883|ROW |S |0|(1,7) |WAIT |T |NULL |T | *** The above row is the victim *** 333883|ROW |X |3|(1,8) |GRANT|T |NULL |T
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-09-ad-nativeAuthenticationService.diff Attaching derby-866-09-ad-nativeAuthenticationService.diff. This is the first rev of a patch which adds a NATIVE authentication service to Derby. Regression tests passed cleanly for me. The patch also passes a battery of ad-hoc tests, but I have not yet collected them into a formal regression test for this new functionality. So the patch is not ready for commit. I am posting the patch now in order to get feedback on whether this approach seems reasonable. The new authentication service follows the pattern of the existing BASIC authentication service (BasicAuthenticationServiceImpl). I did not add support for network password substitution but it may be possible to add that in a later patch. I have taken the approach of normalizing the user name as a SQL identifier when storing credentials at database-creation time. This causes the values in SYSSCHEMAS.AUTHORIZATIONID and SYSUSERS.USERNAME to agree, making it possible to join on those columns. The user name is also normalized at connection-authorization time. I haven't thought through the implications of whether syscs_create_user, syscs_reset_password, and syscs_drop_user should also normalize the username. Your opinions are welcome. Perhaps a clear preference will emerge as I write more tests. Ad-hoc tests have verified the following behavior (at least in simple configurations): 1) Creating a credentials DB. The initial credentials are automatically stored in SYSUSERS and the following properties are persisted: derby.database.sqlAuthorization=true derby.authentication.provider=NATIVE::LOCAL 2) Creating a non-credentials DB, using the credentials DB to authorize the operation. 3) Shutting down a credentials DB and restarting it. 4) Trying to create a database with credentials which are not stored in the credentials DB. This operation fails as expected. 5) Trying to connect to an existing database with credentials which are not stored in the credentials DB. This operation fails as expected. 6) Verifying that the following system property setting is sufficient to turn on authentication and SQL authorization: derby.authentication.provider=NATIVE:$credentialsDB:LOCAL or derby.authentication.provider=NATIVE:$credentialsDB That is, there is no need to also set the following properties: derby.connection.requireAuthentication=true derby.database.sqlAuthorization=true 7) Verifying that a credentials DB remembers that it is a credentials DB. When you reboot it, the connection is authenticated using credentials stored in the local SYSUSERS table. Tests have been run on disk-based and in-memory databases and on desktop and JSR169 platforms. I will start assembling a regression test out of the above cases. Even if my approach needs to be reworked, these tests are a low-bar for any implementation. I know that code has not yet been written to support the following features: i) Prevent NATIVE authentication from being enabled in a pre-existing database which lacks credentials for the DBO. ii) Enable password substitution over the network. Many more tests need to be written. In addition, more code may need to be written in order to implement the full functional spec. At a minimum, the following behaviors need to be verified and perhaps coded: A) Once a credentials database is created, NATIVE authentication cannot be disabled for that database. B) Similarly, SQL authorization cannot be disabled for a credentials DB. C) Upgrade paths have not been tested. D) No testing has been done with databases which are accessed via jar files, the classpath, or http/https URLs. E) No testing has been done over the network. Touches the following files: -- M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java Add a method to retrieve a user's stored credentials. Also added db creation logic to turn on SQL authorization when NATIVE authentication is enabled. -- M java/engine/org/apache/derby/impl/services/monitor/BaseMonitor.java M java/engine/org/apache/derby/iapi/services/monitor/ModuleFactory.java Added a new method which makes it possible for code outside the Store to calculate the canonicalized form of a database name. This is necessary in order to figure out whether the local database is the credentials DB identified by the derby.authentication.provider property. -- M java/engine/org/apache/derby/iapi/services/property/PropertyUtil.java M java/engine/org/apache/derby/iapi/reference/Property.java Added code so that
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-08-ad-passwordHasher.diff Attaching derby-866-08-ad-passwordHasher.diff. This rev of the patch stops users from manipulating NATIVE passwords when derby.authentication.builtin.algorithm is not set. If derby.authentication.builtin.algorithm is not set, then Derby's old-style default password hashing strategy is considered too weak for use by NATIVE authentication. Tests passed cleanly for me with this version of the patch. I do not see much point in further complicating the logic to allow the use of weak hashing with NATIVE authentication. Of course, we could change the meaning of derby.authentication.builtin.algorithm=null when NATIVE authentication is enabled. However, that seems more confusing to me than just forbidding the use of weak hashing altogether. The functional spec should be updated to reflect this change. This version of the patch touches the same files as the previous version plus the following: - M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java New message raised if the user attempts to manipulate a NATIVE password when derby.authentication.builtin.algorithm is not set. - M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java The 10.9 upgrade tests now set derby.authentication.builtin.algorithm if it is not set already. This allows us to test the new NATIVE procedures in databases which were hard-upgraded from Derby versions which did not recognize this property. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-08-aa-passwordHasher.diff Attaching derby-866-08-aa-passwordHasher.diff. This patch wires the NATIVE procedures to the new password hashing scheme which Knut introduced with DERBY-5539. I am running tests now. The patch abstracts the post-10.5 password hashing logic into a new class, PasswordHasher. The logic is now used by the SQL layer as well as the authentication code in the JDBC layer. So I put PasswordHasher in the lower layer. More specifically, I put PasswordHasher in the DataDictionary because authentication code was already calling into the DataDictionary in order to configure password hashing. But other people may have ideas about a better place to park this code--your thoughts are of course welcome. Touches the following files: - M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/jdbc/authentication/BasicAuthenticationServiceImpl.java M java/engine/org/apache/derby/impl/jdbc/authentication/AuthenticationServiceBase.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java A java/engine/org/apache/derby/iapi/sql/dictionary/PasswordHasher.java Abstracts the password hashing code into a PasswordHasher class which lives in the DataDictionary. - M java/engine/org/apache/derby/catalog/SystemProcedures.java Wires the PasswordHasher into syscs_create_user, syscs_modify_password, and syscs_reset_password. - M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java Adds new tests to verify that the NATIVE hashing scheme changes as expected when you tune the BUILTIN knobs which control password hashing. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-08-ab-passwordHasher.diff Attaching derby-866-08-ab-passwordHasher.diff. The previous patch disabled the case when derby.authentication.builtin.algorithm is not set. In that situation, Derby is supposed to default to a SHA-1 message digest. This second rev of the patch seeks to restore the old behavior. Running tests again... Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, derby-866-08-ab-passwordHasher.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-06-aa-upgradeFrom10.1.diff Attaching derby-866-06-aa-upgradeFrom10.1.diff. This patch fixes another regression test which hard-codes the EXECUTE permissions granted on system routines: when testing the hard-upgrade path from 10.1, we verify the tuples in SYS.SYSROUTINEPERMS. This was found by the tinderbox tests after checking in derby-866-03-aa-resetModifyPassword.diff. Committed at subversion revision 1221734. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_2.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-07-aa-removeSQLPassword.diff Attaching derby-866-07-aa-removeSQLPassword.diff. This backs out the addition of the SQLPassword internal datatype. I am running regression tests now. I have been thinking more about the problem which SQLPassword tries to tackle: password Strings are vulnerable to being sniffed in memory, in swap files, and in crash dumps. I have been reading more about the issue and I have come to the conclusion that char[] representations narrow the vulnerability but do not eliminate it. In addition, password maintenance is a rare event compared to the day-to-day event of logging in. As long as JDBC login uses String passwords, I don't see much value in securing password maintenance. The small security boost does not justify the extra complexity of a new, internal-only data type. I am therefore removing SQLPassword. This patch backs out much of derby-866-02-ag-createDropUser.diff (subversion revision 1220807). Touches the following files: M java/engine/org/apache/derby/impl/sql/compile/SQLToJavaValueNode.java M java/engine/org/apache/derby/impl/sql/compile/TypeCompilerFactoryImpl.java M java/engine/org/apache/derby/impl/sql/compile/CharTypeCompiler.java M java/engine/org/apache/derby/impl/sql/GenericParameter.java M java/engine/org/apache/derby/impl/sql/execute/ValueRow.java M java/engine/org/apache/derby/impl/sql/execute/InsertResultSet.java M java/engine/org/apache/derby/impl/sql/execute/IndexValueRow.java M java/engine/org/apache/derby/impl/sql/execute/CardinalityCounter.java M java/engine/org/apache/derby/impl/sql/execute/RowUtil.java M java/engine/org/apache/derby/impl/sql/execute/RIBulkChecker.java M java/engine/org/apache/derby/impl/sql/execute/BaseActivation.java M java/engine/org/apache/derby/impl/sql/execute/TemporaryRowHolderImpl.java M java/engine/org/apache/derby/impl/sql/execute/BasicSortObserver.java M java/engine/org/apache/derby/impl/sql/GenericParameterValueSet.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/sql/GenericActivationHolder.java M java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java M java/engine/org/apache/derby/impl/services/daemon/IndexStatisticsDaemonImpl.java M java/engine/org/apache/derby/iapi/sql/Activation.java M java/engine/org/apache/derby/iapi/sql/execute/ExecRow.java M java/engine/org/apache/derby/iapi/sql/ParameterValueSet.java M java/engine/org/apache/derby/iapi/services/io/RegisteredFormatIds.java M java/engine/org/apache/derby/iapi/services/io/StoredFormatIds.java M java/engine/org/apache/derby/iapi/types/TypeId.java M java/engine/org/apache/derby/iapi/types/DataValueDescriptor.java M java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java M java/engine/org/apache/derby/iapi/types/DataType.java M java/engine/org/apache/derby/iapi/types/ReaderToUTF8Stream.java M java/engine/org/apache/derby/iapi/types/SQLRef.java M java/engine/org/apache/derby/iapi/types/StringDataValue.java M java/engine/org/apache/derby/iapi/types/XML.java D java/engine/org/apache/derby/iapi/types/SQLPassword.java M java/engine/org/apache/derby/iapi/types/SQLChar.java M java/engine/org/apache/derby/iapi/types/SQLVarchar.java M java/engine/org/apache/derby/iapi/types/DataValueFactoryImpl.java M java/engine/org/apache/derby/iapi/types/DataValueFactory.java M java/engine/org/apache/derby/catalog/SystemProcedures.java M java/engine/org/apache/derby/catalog/types/BaseTypeIdImpl.java M java/engine/org/apache/derby/catalog/types/TypesImplInstanceGetter.java M java/testing/org/apache/derbyTesting/unitTests/store/T_AccessRow.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff,
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-03-aa-resetModifyPassword.diff Attaching derby-866-03-aa-resetModifyPassword.diff. This patch adds the syscs_reset_password() and syscs_modify_password() system procedures. I am running tests now. Touches the following files: M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/sql/catalog/SYSUSERSRowFactory.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/catalog/SystemProcedures.java Add new procedures. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java Add test cases for new procedures. M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java Add upgrade sanity check for new procedures. M java/testing/org/apache/derbyTesting/junit/CleanDatabaseTestSetup.java Make test cleanup handle the fact that the credentials for the DBO can't be dropped. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching version 3 of the functional spec. This version incorporates feedback gathered over the past two weeks: 1) Introduces a new value for derby.authentication.provider. When this property is set to the value NATIVE:$credentialsDB:LOCAL, then $credentialsDB is used to authenticate system-wide operations but connections to an individual database are authenticated using credentials stored in its own SYSUSERS table. 2) Fills in the section on Documentation changes. 3) Adds an appendix of sample use cases. This may help people reason about whether the most likely scenarios will be easy to administer. This section may provide a helpful summary for people who don't have time to read the whole spec. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-03-ab-resetModifyPassword.diff Tests ran cleanly for me except for diffs in a couple tests caused by the fact that the new syscs_modify_password() procedure grants EXECUTE privilege to PUBLIC. That in turn adds a new tuple to SYSROUTINEPERMS, causing some tests to fail when they select from that catalog. Attaching derby-866-03-ab-resetModifyPassword.diff. This patch corrects GrantRevokeDDLTest to account for the extra row in SYSROUTINEPERMS. I will fix some other tests in a follow-on patch. Touches another file in addition to the files touched by the previous rev of the patch: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/GrantRevokeDDLTest.java Committed at subversion revision 1221423. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-04-aa-fixRolesTest.diff Attaching derby-866-04-aa-fixRolesTest.diff. This adjusts RolesTest to account for the new tuple in SYSROUTINEPERMS. Committed at subversion revision 1221434. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesTest.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-05-aa-grantRevoke.diff Attaching derby-866-05-aa-grantRevoke.diff. This patch verifies that EXECUTE privilege can be granted and revoked on the new system procedures. Committed at subversion revision 1221456. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, derby-866-03-aa-resetModifyPassword.diff, derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, derby-866-05-aa-grantRevoke.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-02-ag-createDropUser.diff Attaching derby-866-02-ag-createDropUser.diff. This patch adds the syscs_create_user() and syscs_drop_user() system procedures. I will run regression tests. I had originally planned to add just syscs_create_user(). However, I found myself pulling on a ball of yarn because CleanDatabaseSetup needs to return to an initial state as far as possible, and that means dropping users who were added as part of the tests. I ended up pulling on another ball of yarn, which bloated up the number of files touched by this patch: I added StandardException to the exception signature of a method in the string datatypes. This percolated throughout the SQL interpreter, adding StandardException to the signatures of many methods. I debated swallowing the exception lower down and reporting it in the log. However, after some thought I decided that the changed methods all deserved to throw StandardException and should have done so from the start. In implementing syscs_create_user() I faced the problem that the implementing method phrases its password arg as a char[] array rather than a String. In order to get around the method resolution problems, I introduced a new, internal SQLPassword type. This type is not available and is mostly invisible to Derby users. SQLPassword has the following behavior: 1) It appears in DatabaseMetaData.getProcedureColumns() as a VARCHAR type. 2) But its corresponding Java type is char[] rather than String. 3) When the SQL interpreter sees a SQLPassword, it treats the contents as a password which needs to be smudged out as soon as possible. 4) I have found one place where knowledge of this internal type leaks out to users: If you select the aliasinfo of the syscs_create_user() procedure and then call the toString() method on that aliasinfo, you will see that the password arg has type PASSWORD rather than VARCHAR. Touches the following files: M java/engine/org/apache/derby/impl/sql/compile/TypeCompilerFactoryImpl.java M java/engine/org/apache/derby/impl/sql/compile/CharTypeCompiler.java M java/engine/org/apache/derby/impl/sql/compile/SQLToJavaValueNode.java M java/engine/org/apache/derby/iapi/services/io/RegisteredFormatIds.java M java/engine/org/apache/derby/iapi/services/io/StoredFormatIds.java M java/engine/org/apache/derby/iapi/types/TypeId.java M java/engine/org/apache/derby/iapi/types/DataValueDescriptor.java M java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java M java/engine/org/apache/derby/iapi/types/DataType.java M java/engine/org/apache/derby/iapi/types/StringDataValue.java A java/engine/org/apache/derby/iapi/types/SQLPassword.java M java/engine/org/apache/derby/iapi/types/SQLChar.java M java/engine/org/apache/derby/iapi/types/SQLVarchar.java M java/engine/org/apache/derby/iapi/types/DataValueFactoryImpl.java M java/engine/org/apache/derby/iapi/types/DataValueFactory.java M java/engine/org/apache/derby/iapi/types/ReaderToUTF8Stream.java M java/engine/org/apache/derby/catalog/types/BaseTypeIdImpl.java M java/engine/org/apache/derby/catalog/types/TypesImplInstanceGetter.java Support for new internal SQLPassword datatype. M java/storeless/org/apache/derby/impl/storeless/EmptyDictionary.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/catalog/SystemProcedures.java Support for new system procedures syscs_create_user() and syscs_drop_user(). M java/shared/org/apache/derby/shared/common/reference/SQLState.java M java/engine/org/apache/derby/loc/messages.xml New error message. M java/engine/org/apache/derby/impl/sql/GenericParameter.java M java/engine/org/apache/derby/impl/sql/execute/ValueRow.java M java/engine/org/apache/derby/impl/sql/execute/InsertResultSet.java M java/engine/org/apache/derby/impl/sql/execute/IndexValueRow.java M java/engine/org/apache/derby/impl/sql/execute/CardinalityCounter.java M java/engine/org/apache/derby/impl/sql/execute/RowUtil.java M java/engine/org/apache/derby/impl/sql/execute/RIBulkChecker.java M java/engine/org/apache/derby/impl/sql/execute/BaseActivation.java M java/engine/org/apache/derby/impl/sql/execute/TemporaryRowHolderImpl.java M java/engine/org/apache/derby/impl/sql/execute/BasicSortObserver.java M java/engine/org/apache/derby/impl/sql/GenericParameterValueSet.java M
[jira] [Updated] (DERBY-5528) DRDA problem via DB2 client: SQL0901N SQLSTATE=58004
[ https://issues.apache.org/jira/browse/DERBY-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5528: - Urgency: Normal Issue Type: Improvement (was: Bug) I am re-classifying this issue as an enhancement request rather than a bug. Derby uses a network protocol which is based on DRDA. No effort has been put into measuring or describing Derby's divergence from standard DRDA. By now I am fairly sure that Derby diverges from standard DRDA in many ways. DRDA problem via DB2 client: SQL0901N SQLSTATE=58004 Key: DERBY-5528 URL: https://issues.apache.org/jira/browse/DERBY-5528 Project: Derby Issue Type: Improvement Components: Network Client Reporter: Andres Gomez Casanova Labels: client, db2, drda Original Estimate: 24h Remaining Estimate: 24h Hi, I am trying to connect to Derby via DRDA and then via ODBC. To do this, I use the DB2 runtime client that is DRDA compatible. I cataloged the Derby instance and the database. However, I cannot use the database from ODBC. I follow an explanation from IBM, but I cannot get the database because of a DRDA AD problem (Paser Invalid Value) I would like to know if Derby is completely compatible with DRDA. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-01-ab-sysusers.diff Attaching derby-866-01-ab-sysusers.diff. This second rev of the patch adds some additional tests, including an upgrade test. Adds the following tests: 1) Verifies that you can't use views to subvert the authorization checks on SYSUSERS. 2) Verifies that SYSUSERS is created by hard-upgrade but not by soft-upgrade. I ran the upgrade tests against the following list of old releases. I did not see any errors other than the ones which appear without this patch: 10.0.2.1 10.1.1.0 10.1.2.1 10.1.3.1 10.2.1.6 10.2.2.0 10.2.2.1 10.3.1.4 10.3.2.1 10.3.3.0 10.4.1.3 10.4.2.0 10.4.2.1 10.5.1.1 10.5.2.0 10.5.3.0 10.6.1.0 10.6.2.1 10.7.1.1 10.8.1.2 10.8.2.2 Touches an additional file: M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: derby-866-01-aa-sysusers.diff Attaching derby-866-01-aa-sysusers.diff. This first patch adds the SYSUSERS table. I will add upgrade tests in a follow-on patch. I am running regression tests now. This patch makes the following changes: 1) Creates the SYSUSERS table and a unique index on its USERNAME column. This happens in newly created 10.9 databases and in databases which have been hard-upgraded to 10.9. 2) When SQL authorization is enabled, lets only the DBO view SYSUSERS and prevents even the DBO from viewing the PASSWORD column. This patch touches a lot of files for these reasons: i) Adding a new catalog involves touching several data dictionary files. ii) Many of our tests have canonized the results of selects from SYSTABLES. We should consider adjusting these tests so that they will not break the next time we add a catalog. This might be a good task for a newcomer or GSoC student. iii) A couple other files had to be touched because SYSUSERS is a special table with restricted access. Touches the following files: M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java A java/engine/org/apache/derby/impl/sql/catalog/SYSUSERSRowFactory.java M java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java A java/engine/org/apache/derby/iapi/sql/dictionary/UserDescriptor.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/iapi/sql/dictionary/DataDescriptorGenerator.java Adds the SYSUSERS table to the DataDictionary. M java/engine/org/apache/derby/iapi/types/SQLChar.java M java/engine/org/apache/derby/iapi/types/SQLVarchar.java Special logic to allow us to wrap a SQLVarchar around the char[] used to hold a password. This is not intended as general support for representing Strings as char[]. M java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java M java/engine/org/apache/derby/loc/messages.xml M java/shared/org/apache/derby/shared/common/reference/SQLState.java New check to prevent unauthorized viewing of SYSUSERS. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/DBOAccessTest.java New test case to verify that Derby prevents unauthorized viewing of SYSUSERS. M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AlterTableTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/ViewsTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/PrimaryKeyTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/SystemCatalogTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/lang/GrantRevokeDDLTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DMDBugsTest.java M java/testing/org/apache/derbyTesting/functionTests/master/ij7.out M java/testing/org/apache/derbyTesting/functionTests/master/compressTable.out Additional tests which had to be changed because a new catalog appears when you select from SYSTABLES. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Issue fix info: Patch Available Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Assignee: Rick Hillegas Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, derby-866-01-aa-sysusers.diff, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching a third rev of UserManagement.html. This version fills in the Documentation section. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, UserManagement.html, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching a second rev of UserManagement.html. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, UserManagement.html, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: UserManagement.html Attaching a first version of a functional spec for NATIVE user management. This is an attempt to capture the discussion so far. Having a concrete proposal in front of us may help move the discussion forward. Your feedback is appreciated. The following topics need more discussion: 1) This version of the spec does not address the issue of system-wide credentials. I will post a follow-on comment soon which tries to move that discussion forward. 2) This version of the spec phrases password procedure arguments as CLOBs in order to address the Java vulnerability described here: http://securesoftware.blogspot.com/2009/01/java-security-why-not-to-use-string.html An alternative approach would be to introduce a new Derby datatype corresponding to char[]. Other suggestions are welcome. Thanks in advance for reading this spec. Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, UserManagement.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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
[jira] [Updated] (DERBY-866) Derby User Management Enhancements
[ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-866: Attachment: dummyCredentials.properties DummyAuthenticator.java Here is a proposal for how NATIVE user management can handle system-wide users. That is, this proposal handles authenticating orderly engine shutdown, database creation/restoration, and other situations where there is no database in focus. 1) By default, NATIVE authentication successfully authenticates all user/password pairs in system-wide situations. That is, there are no authentication checks preventing orderly engine shutdown and database creation/restoration. In this default mode, Derby is vulnerable to denial-of-service and resource-hogging exploits by anyone who can craft their own connection URLs. 2) We can introduce a new Derby property: derby.authentication.native.credentialsDB. This property can be pointed at a distinguished Derby database. When this property is set, the NATIVE credentials in the distinguished database are used for all authentication. That is, credentials in the distinguished database work for system-wide authentication as well as for ordinary connections to Derby databases. A typical use-case would be a networked Derby application which uses a single database; in this use-case, that database would be set to be the distinguished credentials database. 3) Note that what has been proposed so far merely puts an authentication hurdle in front of denial-of-service and resource-hogging exploits. Any legal user could still shutdown the engine and create unlimited numbers of databases. More protection against these attacks would be provided by completing the system privileges work described by DERBY-2109. A variation on this proposal would be: 2') The distinguished credentials database is only used for system-wide situations. When connecting to an existing Derby database, the NATIVE credentials in that database are used. I think this is a more difficult proposal because it could result in a single identity having to maintain two sets of credentials: a system-wide set and a database-specific set. Note, however, that there is no distinction between (2) and (2') for the typical use-case cited above, in which a single database serves both as the distinguished credentials database as well as the application data store. For extra credit, we might want to make it easy to support the following scenario: A) An application could supply a custom authenticator which relies on NATIVE authentication when authenticating connections to existing databases but which validates system-wide users via LDAP or local OS accounts. I am not sure it is worth spending extra effort to make this scenario easy to support. That is because this usage suffers from the same problem as (2'): a single identity would have to maintain multiple sets of credentials. - More on this problem of multiple credentials for a single identity: It is clear that Derby authentication was designed to make it possible for an identity to have multiple sets of credentials. This feature can be exploited currently by both BUILTIN and application-supplied authentication schemes. However, it does not seem to me that the feature is completely baked. In particular, at database creation time there is no way to tease apart which set of credentials you intend. This forces you to keep both sets in sync. That is because database creation and restoration entail 2 separate credentials checks: an initial check using system-wide credentials followed by a connection attempt using database-specific credentials. If you want to further investigate this double authentication problem, try out the attached DummyAuthenticator and its dummyCredentials.properties file. Boot ij with the following command line and try to create a database: java \ -Dderby.connection.requireAuthentication=true \ -Dderby.authentication.provider=DummyAuthenticator \ -Dderby.database.sqlAuthorization=true \ org.apache.derby.tools.ij Derby User Management Enhancements -- Key: DERBY-866 URL: https://issues.apache.org/jira/browse/DERBY-866 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.2.1.6 Reporter: Francois Orsini Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java, UserManagement.html, dummyCredentials.properties Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently
[jira] [Updated] (DERBY-5510) It is easy to override authentication, authorization, and database-only properties if you have physical access to a database.
[ https://issues.apache.org/jira/browse/DERBY-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5510: - Description: If you have write access to the directory containing a Derby database, then the following easy exploit will let you change the contents of the database and possibly evade detection for some time: 1) Create a vacuous dummy database with this ij command: connect 'jdbc:derby:dummydb;create=true'; 2) Copy the properties conglomerate (c10.dat) from the target database to a side location. 3) Now copy the vacuous c10.dat from dummydb into the seg0 directory of the target database. 4) Now connect to the target database with the following ij command and change anything you want: connect 'jdbc:derby:targetdb'; 5) When you are done, copy c10.dat from the side location back into the seg0 directory of the target database. I do not regard this as a new vulnerability. That is because once you have write access to a Derby database directory, you have unlimited power to change and corrupt the database. However, I am filing this JIRA so that we will have a name for this particular easy exploit. was: If you have write access to the directory containing a Derby database, then the following easy exploit will let you change the contents of the database and possibly evade detection for some time: 1) Create a vacuous dummy database with this ij command: connect 'jdbc:derby:dummydb;create=true'; 2) Copy c10.dat from the target database to a side location. 3) Now copy the vacuous c10.dat from dummydb into the seg0 directory of the target database. 4) Now connect to the target database with the following ij command and change anything you want: connect 'jdbc:derby:targetdb'; 5) When you are done, copy c10.dat from the side location back into the seg0 directory of the target database. I do not regard this as a new vulnerability. That is because once you have write access to a Derby database directory, you have unlimited power to change and corrupt the database. However, I am filing this JIRA so that we will have a name for this particular easy exploit. It is easy to override authentication, authorization, and database-only properties if you have physical access to a database. - Key: DERBY-5510 URL: https://issues.apache.org/jira/browse/DERBY-5510 Project: Derby Issue Type: Bug Components: Miscellaneous Affects Versions: 10.9.0.0 Reporter: Rick Hillegas If you have write access to the directory containing a Derby database, then the following easy exploit will let you change the contents of the database and possibly evade detection for some time: 1) Create a vacuous dummy database with this ij command: connect 'jdbc:derby:dummydb;create=true'; 2) Copy the properties conglomerate (c10.dat) from the target database to a side location. 3) Now copy the vacuous c10.dat from dummydb into the seg0 directory of the target database. 4) Now connect to the target database with the following ij command and change anything you want: connect 'jdbc:derby:targetdb'; 5) When you are done, copy c10.dat from the side location back into the seg0 directory of the target database. I do not regard this as a new vulnerability. That is because once you have write access to a Derby database directory, you have unlimited power to change and corrupt the database. However, I am filing this JIRA so that we will have a name for this particular easy exploit. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-10-ab-metadataTypo.diff Attaching derby-5488-10-ab-metadataTypo.diff. This version of the patch adds a redundant SCOPE_CATLOG column to the end of the ResultSet returned by DatabaseMetaData.getColumns() as Lance and Knut suggested. This bit of defensive logic should reduce the risk of backward incompatibility problems. I am running regression tests now. Touches the same files as the previous version of this patch. Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff, derby-5488-10-aa-metadataTypo.diff, derby-5488-10-ab-metadataTypo.diff, fix-jdbc30-test.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: releaseNote.html Attaching a first rev of a release note to describe backward incompatibilities introduced by renaming a metadata column. Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff, derby-5488-10-aa-metadataTypo.diff, derby-5488-10-ab-metadataTypo.diff, fix-jdbc30-test.diff, releaseNote.html, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-10-ac-metadataTypo.diff Attaching derby-5488-10-ac-metadataTypo.diff. The previous version of the patch raised 2 errors in ViewTest, caused by the fact that DatabaseMetaData.getColumns() now returns a ResultSet with 25 columns rather than 24 columns. This new version of the patch adjusts ViewTest to expect 25 columns. Touches the following additional file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/ViewsTest.java Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff, derby-5488-10-aa-metadataTypo.diff, derby-5488-10-ab-metadataTypo.diff, derby-5488-10-ac-metadataTypo.diff, fix-jdbc30-test.diff, releaseNote.html, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-10-aa-metadataTypo.diff Attaching derby-5488-10-aa-metadataTypo.diff. This a simple candidate patch to change SCOPE_CATLOG to SCOPE_CATALOG. Regression tests pass cleanly on this patch. Before discussing this patch and alternatives we might consider, I want to summarize my understanding of this problem: A) The JDBC expert group regards this as fixing a typo in the javadoc. I believe that some other databases recognized the typo for what it was and always named the column SCOPE_CATALOG. Derby, however, hewed closely to the published javadoc and called the column SCOPE_CATLOG. B) For those other databases, there is no functional change. A documentation typo has simply been corrected. For Derby, however, the change creates a backward incompatibility. C) Derby must break one of its important constraints. There is no way that we can conform to the corrected JDBC javadoc and avoid a backward incompatibility. D) I think that the backward incompatibility is quite minor, nevertheless. The column in question carries no meaning for Derby. The column only has meaning for databases which implement both catalogs and reference types. For Derby, the column always contains a null. I doubt that (m)any Derby users inspect this column at all, let alone by name. Here are the user-visible effects of some possible solutions: 1) Based on engine version - The column is called SCOPE_CATALOG if DatabaseMetaData.getDatabaseMajorVersion() and DatabaseMetaData.getDatabaseMinorVersion() report that the engine is at Derby 10.9 or higher. Otherwise, the column is called SCOPE_CATLOG. This is the approach taken by this patch. 2) Based on client version - The column is called SCOPE_CATALOG if DatabaseMetaData.getDriverMajorVersion() and DatabaseMetaData.getDriverMinorVersion() report that the client is at Derby 10.9 or higher. Otherwise, the column is called SCOPE_CATLOG. 3) Based on JDBC driver version - The column is called SCOPE_CATALOG if DatabaseMetaData.getJDBCMajorVersion() and DatabaseMetaData.getJDBCMinorVersion() report that the driver is at JDBC 4.1 or higher. Otherwise, the column is called SCOPE_CATLOG. Even fancier solutions are possible. They involve combinations of the JDBC and driver versions at the client and engine. I believe that the solutions listed above give rise to straightforward workarounds for applications affected by this change. They are easy to explain. The fancier solutions push more complexity into the application and/or involve backporting tricky code into older Derby branches. Of the straightforward solutions, I opted for (1) because it was the easiest to implement. A casual look at options (2) and (3) suggests that they involve adding some potentially tricky code to our JDBC drivers. I did not think that this problem warranted the additional complexity. But those are my opinions. I am open to arguments that we should solve this problem a different way. Thanks in advance for your feedback. Touches the following files: M java/engine/org/apache/derby/impl/jdbc/metadata.properties M java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java Actual change to the JDBC metadata. M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java Corresponding change to the regression test for this metadata. Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff, derby-5488-10-aa-metadataTypo.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- This message is automatically generated by JIRA. If you think it was sent
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Issue fix info: Patch Available,Release Note Needed (was: Patch Available) Marking the Release note needed flag because of the backward incompatibility introduced by changing SCOPE_CATLOG to SCOPE_CATALOG. Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff, derby-5488-10-aa-metadataTypo.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5490) Lots of error trying to spawn a JVM in the SecureServerTest and Replication tests when running on the preview JDK 7 on Mac OS X
[ https://issues.apache.org/jira/browse/DERBY-5490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5490: - Attachment: derby-5490-03-aa-revert.diff Attaching derby-5490-03-aa-revert.diff. This patch reverts the previous work done on this issue now that DERBY-5504 has provided a more comprehensive solution. I have verified that SecureServerTest and ReplicationSuite run cleanly after applying this reversion. Committed at subversion revision 1203706. Touches the following file: M java/testing/org/apache/derbyTesting/junit/BaseTestCase.java Lots of error trying to spawn a JVM in the SecureServerTest and Replication tests when running on the preview JDK 7 on Mac OS X --- Key: DERBY-5490 URL: https://issues.apache.org/jira/browse/DERBY-5490 Project: Derby Issue Type: Bug Components: Test Environment: OpenJDK Runtime Environment (build 1.7.0-ea-b213) on Mac OS X 10.7 Reporter: Rick Hillegas Fix For: 10.9.0.0 Attachments: derby-5490-01-aa-fixForMac.diff, derby-5490-03-aa-revert.diff I see lots of errors when the tests try to spawn a JVM while running on the OpenJDK 7 preview for Mac OS X. SecureServerTest runs cleanly when I use JDK 6. But I see lots of these errors when I use JDK 7: .java.io.IOException: Cannot run program /Library/Java/JavaVirtualMachines/JDK: error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) at java.lang.Runtime.exec(Runtime.java:615) at java.lang.Runtime.exec(Runtime.java:448) at java.lang.Runtime.exec(Runtime.java:345) at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest$1.run(SecureServerTest.java:487) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runServerCommand(SecureServerTest.java:479) at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runsysinfo(SecureServerTest.java:415) at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:356) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.textui.TestRunner.doRun(TestRunner.java:121) at junit.textui.TestRunner.start(TestRunner.java:185) at junit.textui.TestRunner.main(TestRunner.java:143) Caused by: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.init(UNIXProcess.java:135) at java.lang.ProcessImpl.start(ProcessImpl.java:130) at
[jira] [Updated] (DERBY-5485) Simplify PropertySetter so that it is less brittle and easier to maintain.
[ https://issues.apache.org/jira/browse/DERBY-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5485: - Attachment: derby-5485-02-aa-fixBigDecimalInstantiators.diff Attaching derby-5485-02-aa-fixBigDecimalInstantiators.diff. This fixes org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest so that it runs on JDK 1.4 again. The previous patch broke that test because the compiler was resolving BigDecimal instantiations to an initializer which was introduced in Java 5. This patch changes those instantiations so that they are resolved to an initializer which appears in JDK 1.4. For further information on this problem, see the following derby-dev email thread: http://old.nabble.com/need-theories-about-errors-seen-in-the-jdk-1.4-test-runs-td32842864.html#a32842864 I have successfully run the patched test on Java 6 and JDK 1.4. Committed at subversion revision 1202276. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java Simplify PropertySetter so that it is less brittle and easier to maintain. -- Key: DERBY-5485 URL: https://issues.apache.org/jira/browse/DERBY-5485 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-5485-01-af-simplifyPlusJavadoc.diff, derby-5485-01-ag-changeJDBClevel.diff, derby-5485-01-ah-changeJDBClevel.diff, derby-5485-02-aa-fixBigDecimalInstantiators.diff The PropertySetter task sets up classpath variables so that the build can take advantage of JVM-specific class libraries. Using those libraries makes it possible for the compiler to flag code which is supposed to run on less capable platforms but which calls methods from later JVMs. This is a very tricky problem and we seem to have reached consensus that it requires too much effort to make PropertySetter run correctly in all of the build environments which Derby developers use. I will attach a proposal for how to simplify PropertySetter so that it requires less effort to maintain. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-09-aa-jdbcMinorVersion.diff Attaching derby-5488-09-aa-jdbcMinorVersion.diff. This patch adjusts the JDBC level reported by Derby's drivers when running on Java 6 or later. The new version is 4.1. I am running tests now. Note that 4.1 is the version returned if you are running on Java 6 or Java 7. If you run on Java 6, you can still call the 4.1 methods via reflection. For this reason I believe it makes sense to report 4.1 as the JDBC level on Java 6 even though the platform itself only recognizes the 4.0 methods. Touches the following files: - M java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData40.java Change to embedded DatabaseMetaData.getJDBCMinorVersion(). - M java/client/org/apache/derby/client/net/NetDatabaseMetaData40.java Change to network DatabaseMetaData.getJDBCMinorVersion(). - M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java Change to metadata test. Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, derby-5488-09-aa-jdbcMinorVersion.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-06-aa-limitOffsetTests.diff Attaching derby-5488-06-aa-limitOffsetTests.diff. This patch revamps the OffsetFetchNextTest so that test cases are run against both the SQL Standard syntax and the JDBC limit/offset syntax. Committed at subversion revision 1201020. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/OffsetFetchNextTest.java Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-07-aa-booleanObjects.diff Attaching derby-5488-07-aa-booleanObjects.diff. This patch eliminates the Boolean object creation as Dag recommended. Committed at subversion revision 1201025. Touches the following files: M java/engine/org/apache/derby/impl/sql/compile/SelectNode.java M java/engine/org/apache/derby/impl/sql/compile/UnionNode.java M java/engine/org/apache/derby/impl/sql/compile/RowResultSetNode.java M java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj M java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
[jira] [Updated] (DERBY-5488) Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc.
[ https://issues.apache.org/jira/browse/DERBY-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5488: - Attachment: derby-5488-08-aa-extraLimitOffsetTest.diff Attaching derby-5488-08-aa-extraLimitOffsetTest.diff. This patch adds a couple additional limit/offset tests. Committed at subversion revision 1201041. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/lang/OffsetFetchNextTest.java Add remaining JDBC 4.1 bits which did not appear in the Java 7 javadoc. --- Key: DERBY-5488 URL: https://issues.apache.org/jira/browse/DERBY-5488 Project: Derby Issue Type: Improvement Components: JDBC, SQL Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: JDBC_4.1_Supplement.html, derby-5488-01-aa-objectMappingAndConversion.diff, derby-5488-02-aa-fixBigInteger.diff, derby-5488-03-ac-moveDecimalSetterGetterAndTest.diff, derby-5488-04-aa-fixBigIntegerDecimal.diff, derby-5488-05-ad-limitOffset.diff, derby-5488-06-aa-limitOffsetTests.diff, derby-5488-07-aa-booleanObjects.diff, derby-5488-08-aa-extraLimitOffsetTest.diff, z.java In addition to the JDBC 4.1 bits which were visible in the Java 7 javadoc, a couple other items appear in the JDBC 4.1 Maintenance Review spec. This spec has been published on the JCP website at http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-eval-spec/index.html. I will attach a functional spec for the remaining bits. -- 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
