No "read" FilePermission for JTREG "test.classes" - on Windows only (was Re: RFR 9: 8068578: ...)

[Brent Christian]

Hi,

I ran my updated test through our automated testing system, and it 
failed *on Windows only*.  The toURI() call I added came back with an 
AccessControlException due to not being able to read the "test.classes" 
directory.  The test uses its own security policy.

I added

  permission java.io.FilePermission "<<ALL FILES>>", "read";

to the policy file and the test now passes on all platforms.  So I'll be 
pushing this additional change to the test's policy file.

Anybody know what might be going on - why Windows isn't able to read the 
directory that jtreg creates for test classes?

Thanks,
-Brent

java.security.AccessControlException: access denied 
("java.io.FilePermission" 
"C:\jprt\T\P1\235755.bachrist\s\jdk\testoutput\jdk_io\JTwork\classes\java\io\Serializable\subclassGC" 
"read")
	at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:457)
	at 
java.security.AccessController.checkPermission(AccessController.java:894)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:541)
        at java.lang.SecurityManager.checkRead(SecurityManager.java:880)
        at java.io.File.isDirectory(File.java:844)
        at java.io.File.toURI(File.java:732)
        at SubclassGC.main(SubclassGC.java:53)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at 
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:745)

On 1/23/15 4:15 PM, Brent Christian wrote:
Hi,

Please review this test case update.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8068578
Webrev:
http://cr.openjdk.java.net/~bchristi/8068578/webrev.0/

The test relies on creating a new URLClassLoader and using it to load a
subclass of ObjectOutputStream.  The system classloader is cast to a
URLClassLoader in order to call getURLs(), but the test can be made to
work without this URL[].  We can instead create a URL based on the value
of the "test.classes" system property.

I have confirmed that the test still detects the original bug (6232010)
in 5u6, and passes with later JDKs.

Thanks,
-Brent