db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Installing a SecurityManager by default when the server boots
Date Fri, 09 Nov 2007 09:32:47 GMT
Dyre.Tjeldvoll@Sun.COM writes:

> Rick Hillegas <Richard.Hillegas@Sun.COM> writes:
>
>> As of release 10.3, when you boot the network server from the command
>> line, the server installs a Java SecurityManager with a default
>> policy. This change (DERBY-2196) limits the ability of hackers,
>> connecting from arbitrary machines, to use Derby to corrupt the
>> environment in which it is running. In addition, this change provides
>> a foundation on which we can add more security features
>> incrementally. As a result of this change, we have learned more about
>> how Derby behaves when run under a SecurityManager--that in turn, has
>> helped us discover more permissions which we need to add to the
>> template used as a starting point for configuring a Derby security
>> policy.
>>
>> Unfortunately, this change has proved painful to some users. See, for
>> instance, DERBY-3086 and the ongoing discussion on DERBY-3083.
>>
>> Now that we have some experience with the 10.3 release, I would like
>> to ask the community to review the wisdom of this change. Do we still
>> think that this is the correct default behavior? Or should we consider
>> turning off this feature in the upcoming 10.3 maintenance release?
>
> Personally, I have always been a fan of the "if you don't need it,
> you should not have to pay for it" philosophy. Where "pay" could mean
> anything from a performance hit to extra hassles when getting started.

An example: If I start the Swing-based JUnit test runner with a suite
as argument, it runs fine. But if I try to browse for another suite or test
from the same runner I get

Exception in thread "AWT-EventQueue-0" java.security.AccessControlException: access denied
(java.util.PropertyPermission java.class.path read)
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
        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 junit.runner.ClassPathTestCollector.collectTests(ClassPathTestCollector.java:25)
        at junit.swingui.TestSelector.createTestList(TestSelector.java:257)
        at junit.swingui.TestSelector.<init>(TestSelector.java:125)
        at junit.swingui.TestRunner.browseTestClasses(TestRunner.java:532)
        at junit.swingui.TestRunner$10.actionPerformed(TestRunner.java:348)


Now, what nasty hacker attack is prevented by not letting
JUnit read the classpath :)

-- 
dt

Mime
View raw message