From brent.christian at oracle.com  Thu Jan 29 17:44:53 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 29 Jan 2015 09:44:53 -0800
Subject: No "read" FilePermission for JTREG "test.classes" - on Windows only
	(was Re: RFR 9: 8068578: ...)
In-Reply-To: <54C2E41A.9090609@oracle.com>
References: <54C2E41A.9090609@oracle.com>
Message-ID: <54CA7195.3000609@oracle.com>

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
>

From sean.mullan at oracle.com  Fri Jan 30 15:44:49 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 30 Jan 2015 10:44:49 -0500
Subject: No "read" FilePermission for JTREG "test.classes" - on Windows
	only (was Re: RFR 9: 8068578: ...)
In-Reply-To: <54CA7195.3000609@oracle.com>
References: <54C2E41A.9090609@oracle.com> <54CA7195.3000609@oracle.com>
Message-ID: <54CBA6F1.3030604@oracle.com>

On 01/29/2015 12:44 PM, Brent Christian wrote:
> 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.

Try adding -Djava.security.debug=access to the command line and seeing 
what ProtectionDomain is causing the failure and what permissions have 
been granted to it. There could be a file pathname canonicalization bug 
lurking in there.

--Sean

>
> 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
>>