[ 
https://issues.apache.org/jira/browse/DERBY-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156875#comment-13156875
 ] 

Dag H. Wanvik commented on DERBY-5514:
--------------------------------------

I found that the default test policy has the following entry for EMMA (granted 
to derby.jar)

  // These permissions are needed when testing code instrumented with EMMA.
  // They will only be used if the emma.active system property property is set,
  // which should be set to "" for the permissions to be correct.
  permission java.util.PropertyPermission "${emma.active}user.dir", "read";
  permission java.io.FilePermission "${emma.active}${user.dir}${/}coverage.ec", 
"read, write";
  permission java.lang.RuntimePermission "${emma.active}writeFileDescriptor";

I tried approach two above, to craft a special policy file for the server and 
grant these privileges to *emma.jar* (for SecureServerTest).  This worked in 
part, except for a case where there was a lacking permission for 
writeFileDescriptor (same stack trace as below).

Now, in the tools suite I found a similar issue after running SysinfoLocaleTest:

[junit] java.security.AccessControlException: access denied 
(java.lang.RuntimePermission writeFileDescriptor)
    [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.checkWrite(SecurityManager.java:937)
    [junit]     at java.io.FileOutputStream.<init>(FileOutputStream.java:219)
    [junit]     at 
com.vladium.emma.data.DataFactory$UCFileOutputStream.<init>(DataFactory.java:292)
    [junit]     at 
com.vladium.emma.data.DataFactory$RandomAccessFileOutputStream.<init>(DataFactory.java:375)
    [junit]     at 
com.vladium.emma.data.DataFactory.writeEntry(DataFactory.java:715)
    [junit]     at 
com.vladium.emma.data.DataFactory.persist(DataFactory.java:672)
    [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)

except this time there is no spawned VM, so the code is running under the 
default test policy, which does have the EMMA permissions shown above. Note 
that this thread doesn't have any code from derby.jar on the stack, so the fact 
the derby.jar has the required privileges doesn't help: we still get 
AccessControlException.

I downloaded the EMMA sources and wrapped the call to 
RTCoverageDataPersister#DataFactory.persist (cdataView, outFile, merge) in a 
doPrivilegedException call. That made it work. 

There is no other use of doPrivileged in EMMA's code, so we may see other 
similar problems.

The exception seen above is later followed by this warning:

  [report] processing input file 
[/export/home/dag/java/sb/sb1/junit_20111124_1520/coverage.ec] ...
  [report] java.io.UTFDataFormatException: malformed input around byte 0

which is may be the (partial?) reason why the coverage file gets corrupted.

                
> SecureServerTest doesn'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: 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

        

Reply via email to