Hi Alan,

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-boun...@openjdk.java.net> On
> Behalf Of Alan Bateman
> Sent: Montag, 23. März 2020 20:19
> To: Doerr, Martin <martin.do...@sap.com>; core-libs-
> d...@openjdk.java.net; jdk-updates-...@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

Reply via email to