[ipv6] Regarding 8220673: Add test library support for determining platform IP support

[Arthur Eubanks]

>
> > IIUC, a security manager that disallows everything would prevent the
> > code in IPSupport from working at all, and there's no way to get around
> > it with doPrivileged() since IPSupport and System.getProperty() are not
> > in the same protection domain. So something like IPSupport would need to
> > be in java.base, which doesn't make sense.
>
> Some tests in the code base use policy files and arrange to grant all
> permissions to the library code.

Ah, I thought we wanted to be able to use IPSupport without having to
specify permissions in a policy file. Having to modify a policy file makes
IPSupport a leaky abstraction, but I suppose there's no way around it.

>
> > None of the tests touched in this change start failing. Given that fact,
> > does it make sense that tests in the future that test SecurityManagers
> > and networking should not use IPSupport, since it would be unreliable?
>
> The library code should have the appropriate doPrivileged block so that
> the test or jtreg infrastructure can grant the appropriate permissions
> to the library code, and shield the test itself from whatever permission
> the library requires.
>
> > And what do you mean by double checking?
>
> Well - some tests could be designed to check that a security
> exception is thrown. We should double check whether any test you
> modified that has a security manager is trying to do that, and
> verify that your proposed change doesn't cause such security
> exception to be thrown by the library code instead.
> The test could be quite happy, but no longer testing what it's
> supposed to test if that happened.
>
> Adding the doPrivileged in the library code is only half of the
> answer: we must also make sure that any such test has also
> the proper magic in place to make sure the library code is
> granted the permission it needs. I believe we had this issue
> in the past. I'll try to find out whatever we did to solve it.
>
When you said "double checking" I thought it was some terminology related
to security managers (e.g. "double checked locking") :P
I looked through all the tests I modified for any references to security
managers or policy files (grep "security" and "policy"). There is
one, test/jdk/java/net/InetAddress/GetLocalHostWithSM.java, but the call to
IPSupport is before the test sets the SecurityManager.
So the existing tests should not be affected by this.


With help from Chris's references ([1]), I added a test with a policy file
that grants IPSupport permission to listen/resolve localhost:0, and read
the java.net.preferIPv4Stack system property. Without either permission,
the test fails as expected.
One thing I discovered is that to make the policy file work properly with
the jtreg directory structure, I needed to add "@build
jdk.test.lib.net.IPSupport" to the test. So any test that wants to use
IPSupport and security managers needs to have that extra line and make sure
that its policy file contains all the permissions as in the new test policy
I added.
Without "@build jdk.test.lib.net.IPSupport", the policy file would need grant
codeBase "file:${test.classes}/-"
With "@build jdk.test.lib.net.IPSupport", the policy file needs grant
codeBase "file:${test.classes}/../../../../test/lib/-"
This matches [1], and seems more restrictive (only applies to test library
code) and better.

New webrev: http://cr.openjdk.java.net/~aeubanks/8220673/webrev.03/

[1]:
https://hg.openjdk.java.net/jdk/jdk/file/1dc9bf9d016b/test/jdk/java/net/httpclient/AsFileDownloadTest.policy#l24
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190507/f0fc5a7f/attachment-0001.html>