I'm in favor of Peters approach ( I would need to do a more detailed
review though ).
Looking up name service providers during initialization of InetAddress
has been the cause of several issues in the past.
I agree with Stanimir's point about TCCL, but I don't think we should
try to do anything about it. If some application depends on having a
particular thread, with a "special" TCCL set, initialize InetAddress,
then it is just broken.
I would prefer to keep this code as simple as possible, and stashing the
TCCL for later use just adds complication.
-Chris.
On 20/06/14 13:16, Stanimir Simeonoff wrote:
Hi Peter,
Irrc, ServiceLoader.load(NameServiceDescriptor.class) uses
Thread.contextClassLoader to load the services. Depending how late the
NameServices is getting initialized, perhaps it can be used to
circumvent the loader available at clinit of InetAddress.
I am not sure it could be a real security concern (as the caller has to
be authorized to create custom classloaders), yet the behavior is not
exactly the same. Storing Thread.currentThread().getContextClassLoader()
during clinit in a WeakRefernce (and clearing on use) should be closest
to the original code.
Cheers,
Stanimir
On Fri, Jun 20, 2014 at 2:20 PM, Peter Levart <peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>> wrote:
On 06/20/2014 11:10 AM, Peter Levart wrote:
Perhaps a more lazy initialization of NetworkInterface class
that does not trigger initialization of NS providers could help.
We just need to invoke two methods on NetworkInterface:
- static NetworkInterface.__getNetworkInterfaces()
- instance NetworkInterface.__getHardwareAddress()
both of which could provide the result without the need of NS
providers, I think.
This would solve the most general case of using TLR. The case
that doesn't involve SecureRandom's help which I think is rarely
needed and not default.
Regards, Peter
Hi,
A patch that solves this is a patch to InetAddress. We can't
suppress initialization of InetAddress as part of NetworkInterface
initialization, but we can suppress initialization of NameService
providers as part of InetAddress initialization by moving them into
a nested class called NameServices:
http://cr.openjdk.java.net/~__plevart/jdk9-dev/InetAddress.__NameServices/webrev.01/
<http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.NameServices/webrev.01/>
This should solve Martin's issue, but the patch to TLR
initialization could be applied nevertheless, since it might help
overcome possible issues when using SecureRandom for TLR's seed.
Regards, Peter
_________________________________________________
Concurrency-interest mailing list
Concurrency-interest@cs.__oswego.edu
<mailto:concurrency-inter...@cs.oswego.edu>
http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
<http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
_______________________________________________
Concurrency-interest mailing list
concurrency-inter...@cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
