db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5514) SecureServerTest (and others) don't play nice with EMMA: AccessControlException
Date Fri, 25 Nov 2011 10:52:40 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-5514:

    Attachment: d5514-emma-permissions-to-all.diff

Thanks for that info, Dag! So it seems that the problem is that the JVM's runtime libraries
don't have the permissions required by the EMMA code, and the lack of doPrivileged blocks
in EMMA requires all code to have those permissions (except if Derby code that contains doPrivileged
blocks itself is on the stack and limits the privilege checking).

Based on that observation, I tried a different approach that didn't require modifying the
EMMA source (see d5514-emma-permissions-to-all.diff). Instead, I changed the policy files
to grant the permissions required by EMMA to all code bases when running with the instrumented
code. That's basically the same as the current policy files do, except they explicitly grant
the permissions to all the jar files we know about, whereas my patch grants them to all code
bases the JVM knows about. (This also simplifies the policy files a bit, since we now only
need one grant rule that covers all code bases, instead of one grant rule per code base.)

I ran "ant -DderbyTesting.oldReleasePath=... emma-all" with my attached patch and Dag's initial
patch for SecureServerTest. I saw two failures in RuntimeInfoTest, but it sounds like Dag
already has a fix for that test in his sandbox (by setting the emma.verbosity.level property?).

I also had to make a small change to RoutineSecurityTest. It contained negative test cases
that tried to get the value of various system properties from within a stored procedure. Among
these properties were user.dir, on which EMMA requires a read permission. Since EMMA's permissions
are now granted to a wider set of code bases, getting that property now unexpectedly succeeded.

Because of this, the patch skips the negative test case for user.dir. There are negative test
cases for many other system properties, so I think RoutineSecurityTest still tests what it
intended to test. Also, as a compensation, I enabled the negative test case for the user.home
property in the same test. That test case has been disabled since the test was first checked
in, but there is no comment saying why it's disabled, and it didn't fail in my environment
(tested from both classes and jars, since they have different permissions granted to them,
and also both sane and insane).
> SecureServerTest (and others) don't play nice with EMMA: AccessControlException
> -------------------------------------------------------------------------------
>                 Key: DERBY-5514
>                 URL: https://issues.apache.org/jira/browse/DERBY-5514
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:
>            Reporter: Dag H. Wanvik
>         Attachments: d5514-emma-permissions-to-all.diff, derby-5514-1.diff, derby-5514-1.stat
> When running SecureServerTest with jars instrumented with EMMA using the ant emma-all
target, I see:
> [junit] (net)derbynet.SecureServerTest.testServerStartup used 8475 ms junit.framework.TestListener:
>     [junit] START-SPAWNED:SpawnedNetworkServer ERROR OUTPUT:
>     [junit] java.security.policy: error adding Entry:
>     [junit] 	java.net.MalformedURLException: no protocol: /export/home/dag/java/sb/sb1/tools/java/emma.jar
>     [junit] java.security.AccessControlException: access denied (java.io.FilePermission
coverage.ec read)
>     [junit] 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
>     [junit] 	at java.security.AccessController.checkPermission(AccessController.java:546)
>     [junit] 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
>     [junit] 	at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
>     [junit] 	at java.io.File.exists(File.java:731)
>     [junit] 	at com.vladium.emma.data.DataFactory.persist(DataFactory.java:525)
>     [junit] 	at com.vladium.emma.data.DataFactory.persist(DataFactory.java:86)
>     [junit] 	at com.vladium.emma.rt.RTCoverageDataPersister.dumpCoverageData(RTCoverageDataPersister.java:54)
>     [junit] 	at com.vladium.emma.rt.RTExitHook.run(RTExitHook.java:32)
>     [junit] 	at java.lang.Thread.run(Thread.java:662)
>     [junit] Exception in thread "EMMA shutdown handler thread" java.lang.RuntimeException:
EMMA failed to dump coverage data: java.security.AccessControlException: access denied (java.io.FilePermission
coverage.ec read)
>     [junit] 	at com.vladium.emma.rt.RTCoverageDataPersister.dumpCoverageData(RTCoverageDataPersister.java:71)
>     [junit] 	at com.vladium.emma.rt.RTExitHook.run(RTExitHook.java:32)
>     [junit] 	at java.lang.Thread.run(Thread.java:662)
>     [junit] END-SPAWNED  :SpawnedNetworkServer ERROR OUTPUT:
> This is presumably because the test spawns a server which runs with the default server
> Another thing is that is seems dangerous to let the spawned process write to EMMA's "coverage.ec",
since we don't know when the parent process will write to it. This behavior could be what's
been causing our corrutions in the EMMA runs earlier. The missing permissions just highlight
what's happening.
> In this case the spawned process was started with this command line (I instrumented the
> XXX server startup command = /usr/jdk/instances/jdk1.6.0/jre/bin/java -classpath /<my
sandbox>/tools/java/emma.jar:/<my sandbox>/jars/sane/derbyTesting.jar:/<my sandbox>/jars/emma/lib/derbyclient.jar:/<my
sandbox>/jars/emma/lib/derbynet.jar:/<my sandbox>/jars/emma/lib/derby.jar:/<my
sandbox>/jars/emma/lib/derbytools.jar:/<my sandbox>/jars/emma/lib/derbyrun.jar:/<my
org.apache.derby.drda.NetworkServerControl start -h localhost -p 1527 
> Possible approaches:
>          run the spawned VMs with plain jars (downside: we won't get coverage for those)
>          run the spawned with a special default policy file when we run with EMMA ++
>          run the spawned VM with -noSecurityManager if with EMMA jars

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message