[
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: 10.9.0.0
> 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: endTest(testServerStartup)
> [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 policy.
> 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 code):
> 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
> sandbox>/tools/java/junit.jar:/usr/share/lib/ant/ant-launcher.jar:/usr/share/lib/ant/ant.jar:/usr/share/lib/ant/ant-junit.jar
> 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
