[ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1

[Arthur Eubanks]

Looks like this test is now failing, I'll take a look tomorrow, sorry about
this.

On Wed, May 22, 2019, 12:48 PM Sean Mullan <sean.mullan at oracle.com> wrote:

> On 5/22/19 3:33 PM, Arthur Eubanks wrote:
> >
> >
> > On Wed, May 22, 2019 at 12:12 PM Sean Mullan <sean.mullan at oracle.com
> > <mailto:sean.mullan at oracle.com>> wrote:
> >
> >     On 5/22/19 1:28 PM, Arthur Eubanks wrote:
> >      > On Wed, May 22, 2019 at 7:13 AM Daniel Fuchs
> >     <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
> >      > <mailto:daniel.fuchs at oracle.com
> >     <mailto:daniel.fuchs at oracle.com>>> wrote:
> >      >
> >      >     Hi Arthur,
> >      >
> >      >         18 // For IPSupport
> >      >         19 grant {
> >      >         20     permission java.net.SocketPermission "localhost:0",
> >      >     "listen,resolve";
> >      >         21     permission java.util.PropertyPermission
> >      >     "java.net.preferIPv4Stack", "read";
> >      >         22 };
> >      >
> >      >     It might be better if these permissions were granted to the
> >      >     library only.
> >      >
> >      > Done.
> >
> >     Have you tested that with jtreg? I believe it may not work because of
> >     the way the SecurityManager is enabled inside the test (rather than
> >     using the jtreg java.security.policy option). You may find that you
> >     also
> >     need to grant those permissions to jtreg.jar since it is higher in
> the
> >     call stack. If that is the case, you are probably better off granting
> >     the permissions to all code, or restructuring the test to use the
> jtreg
> >     java.security.policy option, where jtreg installs its own
> >     SecurityManager to grant itself the proper permissions. However, that
> >     will require some code changes and granting some additional
> permissions
> >     to the test that are needed (for adding a security provider, etc)
> >     before
> >     it currently enables a SM. And that is probably more than you want
> >     to do
> >     for this fix.
> >
> >     --Sean
> >
> > Tried it directly with jtreg
> > $ ~/jtreg/build/images/jtreg/bin/jtreg -jdk:./images/jdk/
> > ../test/jdk/java/security/SecureClassLoader/DefineClass.java
> > and it passes. Verified that removing the newly added permissions makes
> > it fail again.
> > There was some discussion on IPSupport and SecurityManagers when
> > IPSupport was first introduced:
> > https://markmail.org/message/vvemfm367ja3qllj
>
> Ok, the fix looks good then to me.
>
> --Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190522/f5656ac3/attachment-0001.html>