There are test failures, which seems to be caused by a bug in jtreg tool. For example,
see failure reported in CR 6983028.

Note that the regression test itself is not involved into stack trace reported there: for some reason,
the jtreg code has no permission to access the log file.

To demonstrate this problem more clearly I have created simple test (see it attached),
which always reports success and run it in following ways:

a) @run main/othervm SimpleSecurityTest
b) @run main/othervm/secure=java.lang.SecurityManager/policy=security.policy SimpleSecurityTest
c) @run main/othervm/secure=java.lang.SecurityManager SimpleSecurityTest

Ways a) and b) work fine, but c) always fails due to lack of permissions:
Exception in thread "main" java.security.AccessControlException: access denied (
java.io.FilePermission C:\work\jdk_ws\2d.fixes\jdk\test\JTwork\classes\java\awt\SimpleSecurityTest.jta 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.checkRead(SecurityManager.java:871)
        at java.io.FileInputStream.<init>(FileInputStream.java:100)
        at java.io.FileInputStream.<init>(FileInputStream.java:66)
        at java.io.FileReader.<init>(FileReader.java:41)
        at com.sun.javatest.regtest.MainWrapper.main(MainWrapper.java:45)

Note that c) if perfectly legal from the spec point of view according to tag-spec.txt:

    /secure=<class>

Specify a subclass of java.lang.SecurityManager to be installed as the security
manager. An appropriate @build tag should be provided to ensure that the class
is compiled. If the /secure option is used without the /policy option then the
system's built-in policy, equivalent to the original sandbox policy, will be
assumed.

This problem can be reproduced with following releases of jtreg: 3.2.2_03, 4.0, and 4.1