db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Security manager problems with Class.forName()
Date Thu, 02 Mar 2006 21:49:45 GMT
Rick Hillegas wrote:

> Hi Kristian,
>
> I believe you have run into DERBY-623. I am attaching a patched 
> version of BaseMonitor which fixes this problem for me. I haven't' run 
> derbyall against this yet so I can't verify that it's safe. But 
> methinks it will work for you.
>
You are correct Rick. Thanks for the info!
I must take some time and search Jira (and the archives) before I post 
to dev next time I stumble over something that looks like a bug...

I just looked at the patch quickly, and it solves the problem in the 
same way I was thinking about. I will try it out. Any specific reason 
why the patch is not attached to DERBY-623 in Jira?

Also, the issue description indicates that there are already methods for 
reading system properties in privileged blocks "in the engine". Can 
anyone familiar with the code give a hint?


I would like to see this bug fixed, and I am willing to put some work 
into it (review, or possibly fix patch to use existing functionality), 
unless someone else has the itch for it. I suppose another part of the 
fix would be to remove the extra PropertyPermissions from the test 
security policy.



--
Kristian
 

> Regards,
> -Rick
>
>
> Kristian Waagan wrote:
>
>> Hello,
>>
>> I have run into a problem when running a JDBC4 JUnit test. The test 
>> is compiled with Mustang (Java 1.6), and all you need in the test for 
>> the problem to arise is a 
>> 'Class.forName("org.apache.derby.jdbc.EmbeddedDriver")'.
>>
>> When the above codeline is executed, a 
>> java.lang.ExceptionInInitializerError is raised with the following 
>> cause:
>> Caused by: java.security.AccessControlException: access denied 
>> (java.util.PropertyPermission derby.debug.false read)
>>         at 
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:321)

>>
>>         at 
>> java.security.AccessController.checkPermission(AccessController.java:546) 
>>
>>         at 
>> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>>         at 
>> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
>>         at java.lang.System.getProperty(System.java:652)
>>         at 
>> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown 
>> Source)         at 
>> org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown 
>> Source)         at 
>> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown 
>> Source)         at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown 
>> Source)         at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown 
>> Source)         at 
>> org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)         
>> ... 18 more
>>
>>
>>
>> The code causing the error is only reachable in sane builds, and is 
>> located in 'impl.services.monitor.BaseMonitor.runWithState()':
>> if (SanityManager.DEBUG) {
>>     // Look for the derby.debug.* properties.
>>     if (applicationProperties != null) {
>>         // MODIFIED [snip]
>>     }
>>
>>     // MODIFIED - The error happens here!
>>     addDebugFlags(System.getProperty(Monitor.DEBUG_FALSE), false);
>>     addDebugFlags(System.getProperty(Monitor.DEBUG_TRUE), true);    }
>>
>>
>> There are at least two workarounds; grant more permissions in the 
>> derby_test.policy file (without a codebase argument), or use a 
>> doPrivileged-block around the Class.forName() call.
>>
>> However, the two options above do not seem right to me.
>> Can we move the doPrivileged-block down into the BaseMonitor class?
>> There is also a Properties variable in BaseMonitor named 
>> systemProperties, but glancing at the code tells me it might be null 
>> (haven't checked the consequences of that).
>>
>>
>> Can anyone advice on this?
>>
>>
>>
>>
>> -- 
>> Kristian
>
>
>
[snip - BaseMonitor patch]

Mime
View raw message