db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1001) Rewrite 'store/encryptionKey.sql' to a JUnit test
Date Tue, 17 Oct 2006 14:32:37 GMT
    [ 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:
>            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

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


View raw message