[
http://issues.apache.org/jira/browse/DERBY-1001?page=comments#action_12439811 ]
Kristian Waagan commented on DERBY-1001:
----------------------------------------
I have rewritten the test to JUnit, but have problems with the file permissions.
As far as I can see, the offending call is made from JUnit, propagates through
derby.jar and fails with this stack trace:
1)
testRestoreFrom(org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyDESTest)java.security.AccessControlException:
access denied (java.io.FilePermission extinout/encryptionKeyDBToRestoreFrom
read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:700)
at
org.apache.derby.impl.services.monitor.StorageFactoryService.recreateServiceRoot(StorageFactoryService.java:579)
at
org.apache.derby.impl.services.monitor.StorageFactoryService.getServiceProperties(StorageFactoryService.java:252)
at
org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1544)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:991)
at
org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:542)
at
org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1632)
at
org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:223)
at
org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
at
org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:74)
at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:210)
at
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:117)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:171)
at
org.apache.derbyTesting.junit.TestConfiguration.getConnection(TestConfiguration.java:456)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.getConnection(BaseJDBCTestCase.java:236)
at
org.apache.derbyTesting.functionTests.tests.store.EncryptionKeyTest.testRestoreFrom(EncryptionKeyTest.java:166)
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:76)
The exception is thrown both when running as JUnit standalone and through the
test harness.
What is the correct solution to this problem?
a) Add read permission to all for ${user.dir}${/}extinout${/}-
Added to all to include junit.jar, since it can be anywhere on the system.
b) Wrap relevant file operations derby.jar in doPrivileged.
c) Would it be possible to wrap "something" inside a doPrivileged in
derbyTesting.jar
d) Other solutions?
I think maybe b) is not the way to go, since the files Derby needs to read may
be anywhere.
I lean towards considering this problem as a pure test problem, but I might
have misunderstood.
> Rewrite 'store/encryptionKey.sql' to a JUnit test
> -------------------------------------------------
>
> Key: DERBY-1001
> URL: http://issues.apache.org/jira/browse/DERBY-1001
> Project: Derby
> Issue Type: Test
> Components: Test
> Affects Versions: 10.2.1.6
> Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
> Priority: Minor
>
> This test has failed on Solaris10 for a long time, due to issues with the
> default security provider on this OS. See DERBY-788 for details.
> I consider rewriting this test as interresting because it allows us to see
> how things can be done in "the JUnit way".
> 1) Run test with multiple encryption algorithms with minimal test code
> duplication.
> 2) Special handling of exceptions for specific providers (PCKS11-Solaris).
> The rewritten test might cause some discussion on how we want to handle the
> issues mentioned above.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
