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:
-Djava.security.policy=\\host\Users\duke\java.policy
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:
-Djava.security.policy=file:\\host\Users\duke\java.policy
will not work because it ignores the hostname and tries to load
\Users\duke\java.policy. However:
-Djava.security.policy=file:\\\\host\Users\duke\java.policy
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.
--Sean
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 [email protected], maybe someone there can give a clear answer.
Thanks,
Max
On Mar 6, 2019, at 3:53 AM, Sean Mullan <[email protected]> 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
