[concurrency-interest] ThreadLocalRandom clinit troubles

[Chris Hegarty]

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.levart at gmail.com
> <mailto:peter.levart at 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 at cs.__oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/__listinfo/concurrency-interest
>     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>