[jboss-user] [JBoss Microcontainer Development] New message: "Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA"

Flavia Rainone do-not-reply at jboss.com
Mon Mar 8 13:43:00 EST 2010

User development,

A new message was posted in the thread "Security problems with org.jboss.test:jboss-test 1.1.5.GA":


Author  : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com

> mailto:adrian at jboss.org wrote:
> Looks like a bug to me, but I don't see any recent changes in the code that would cause the problem?
> The SecurityManager shouldn't be installed until it runs AbstractTestDelegate.setUp()
> The error above is happening in the constructor of the delegate.
> Its only after that happens that you can do:
> delegate.enableSecurity = true;
> Most likely, there is a security manager still around from a previous test?
You're right!
Taking a better look, I found this:
public class AOPTestDelegate extends AbstractTestDelegate
    public void tearDown() throws Exception
>>>       //TODO Figure out cause of security exception when making this call
>>> //       super.tearDown();
       String deployedByClassLoader = (String)systemProps.get(EclipseTestTransformer.CLASSLOADER_DEPLOYED_XML); 
       if (deployedByClassLoader != null)
          URL url = Thread.currentThread().getContextClassLoader().getResource(deployedByClassLoader);

AbstractTestDelegate.setUpSecurity defines a SecurityManager, and AbstractTestDelegate.tearDownSecurity should set the SecurityManager as null. This is not happening, because AbstractTestDelegate.tearDown is overwritten and the call to super.tearDown is commented out.
Uncomenting this call took me to:
Testcase: testBasic took 1.531 sec
        Caused an ERROR
access denied (java.lang.RuntimePermission setSecurityManager)
java.security.AccessControlException: access denied (java.lang.RuntimePermission setSecurityManager)
        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.System.setSecurityManager0(System.java:272)
        at java.lang.System.setSecurityManager(System.java:263)
        at org.jboss.test.AbstractTestDelegate.tearDownSecurity(AbstractTestDelegate.java:195)
        at org.jboss.test.AbstractTestDelegate.tearDown(AbstractTestDelegate.java:142)
        at org.jboss.test.aop.AOPTestDelegate.tearDown(AOPTestDelegate.java:66)
        at org.jboss.test.AbstractTestSetup.tearDown(AbstractTestSetup.java:73)
        at org.jboss.test.AbstractTestCaseWithSetup.tearDown(AbstractTestCaseWithSetup.java:112)

>From that, I'm assuming that I should define a security policy that allow AbstractTestDelegate to call setSecurityManager. Is that correct?


To reply to this message visit the message page: http://community.jboss.org/message/530617#530617

More information about the jboss-user mailing list