[ http://issues.apache.org/jira/browse/DERBY-1001?page=comments#action_12442918 ] Kristian Waagan commented on DERBY-1001: ----------------------------------------
I might be confused, so I'll write out my thoughts and people can correct me. Since the path we need (read) access to is specified by the user in the connection string, I thought these permissions should not be granted to the Derby codebase, but rather for the application codebase using Derby. This would mean the application would have to do a doPrivileged when restoring/creating the database. [1] says: "... the call to doPrivileged should be made in the code that wants to enable its privileges." After the connection has been made, Derby's "core permissions" should be sufficient to ensure normal operation again. However, when running the network server, the approach mentioned above will not work, and permissions to the backup locations would have to be granted to derby.jar, not the application code. Then adding doPrivileged-blocks to the derby.jar codebase is reasonable. I think also I forgot that our policy file is just an example and for a specific use (for instance running the tests). For a concrete deployment, the user/administrator must add the proper permissions. The fact that Derby was able to write the backup, but not read it, must be attributed to more extensive usage of doPrivileged-blocks in one code path over the other. I suppose the default policy file and the tests must be written to be compatible with each other, and I think they will be if we add more doPrivileged-blocks. My initial concern was why other actions in the area are wrapped in doPrivileged-blocks, while the backupRoot.exists() is not. Thought there could be was a reason for that. Does this make any sense? [1] http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html > 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
