TIL that we had tests with security policies so fine-grained that test
libraries were granted more permissions than other test code.
grant codeBase "file:${test.classes}/../../../../test/lib/-" {
Given that, I agree with Chris and Daniel that test library code should
include the same doPrivileged blocks that the JDK proper would.
*From: *Daniel Fuchs <daniel.fu...@oracle.com>
*Date: *Tue, May 7, 2019 at 6:54 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list
Hi Arthur,
>
> On 07/05/2019 00:50, Arthur Eubanks wrote:
> [...]
> > 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.
>
> > 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.
>
>
> [...]
>
> > hasIPv4 and hasIPv6 will both be false when IPv4 is not available
> > and java.net.preferIPv4Stack is true. In this case we should throw a
> > jtreg.SkippedException, not an AssertionError.
> > We can throw an AssertionError if java.net.preferIPv4Stack is not true
> > and both IPv4 and IPv6 are not available (meaning there's something
> > wrong with the system). This should catch things like binds not working.
>
> That would be quite reasonable. Thanks.
>
> > New webrev (only IPSupport was changed):
> > http://cr.openjdk.java.net/~aeubanks/8220673/webrev.02/
>
> I still believe the library code should have the appropriate
> doPrivileged, and then we need to double check whether anything
> more is needed (whether any policy file / custom Policy or
> custom security manager that modified tests are using need
> any updates to grant permission to library code).
>
> best regards,
>
> -- daniel
>
>
