[11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

[Langer, Christoph]

Hi Alan,

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Alan Bateman
> Sent: Montag, 23. März 2020 20:19
> To: Doerr, Martin <martin.doerr at sap.com>; core-libs-
> dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> On 23/03/2020 18:07, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to backport JDK-8223326 from jdk/jdk.
> >
> > 11u backport issue:
> > https://bugs.openjdk.java.net/browse/JDK-8241460
> >
> > Original change:
> > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
> >
> > 11u backport webrev:
> > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
> >
> > I had to integrate the change manually due to context changes. However,
> the new code fits to the 11u versions.
> >
> > Please review.
> >
> Socket(SocketImpl) is only specified to do a permission check when the
> impl is non-null. The socket adaptor in JDK 12 and older releases
> doesn't have a dummy impl so the change should not be needed. If there
> is a security exception thrownhere then it suggests something may be
> broken elsewhere, do you have a stack trace?

I think you are completely right, that change is not required for 11u as it stands.

ServerSocketAdaptor::create in 11u would never enter a path that does a permission check and for SocketAdaptor:create the Socket constructor is called with a null impl, so checkPermission(null) will immediately return null.

We also don't have an indication that something is broken. My team is just doing an exercise to go through private JBS bugs that have been resolved in jdk/jdk after JDK11 was released and tries to asses which ones should/need to go into OpenJDK 11 updates, too. That's because we wouldn't see when Oracle would backport such bugs for their Oracle 11 Updates and we fear we'd miss something important otherwise.

But I suggest to withdraw this backport of JDK-8223326 and set JDK-8241460 to "Won't Fix".

Best regards
Christoph