RFR [13]: 8218618: Program fails when using JDK addressed by UNC path and using Security Manager

Sean Mullan sean.mullan at oracle.com
Thu Mar 7 15:02:39 UTC 2019

On 3/5/19 7:50 PM, Weijun Wang wrote:
> The fix looks fine to me.
> However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy?

If you specify the UNC policy file as just a file pathname (and not a 
"file:" URL), ex:


In this case, the Policy implementation converts the canonical form of 
the path into an encoded "file:" URL (see 
sun.net.www.ParseUtil.fileToEncodedURL) and the URL works when passed to 
PolicyUtil.getInputStream (which decodes it into a path and opens it 
with FileInputStream).

However, if you specify the UNC policy file as a "file:" URL, it depends 
on the user getting the proper URL encoding (escaped characters, etc) 
right. For example:


will not work because it ignores the hostname and tries to load 
\Users\duke\java.policy. However:


does work. I'm not entirely sure, but I think it has something to do 
with escaping the leading backslashes so that it is not considered a 
host part of the URL.

There's possibly some unnecessary overhead encoding the path into a URL 
and decoding back again, but I don't want to tinker with it unless there 
is a known issue.


> I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer.
> Thanks,
> Max
>> On Mar 6, 2019, at 3:53 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>> Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError.
>> The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard).
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/
>> bugid: https://bugs.openjdk.java.net/browse/JDK-8218618
>> --Sean

More information about the core-libs-dev mailing list