On 19/06/2014 05:25, Martin Buchholz wrote:
ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some networking code to get some
more machine-specific entropy in initialSeed(). This will fail if the
networking code ever recursively uses a (not yet functional)
ThreadLocalRandom. The clinit for InetAddress can cause arbitrary code to
be run,
at
java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
at java.net.InetAddress$3.run(InetAddress.java:923)
at java.net.InetAddress$3.run(InetAddress.java:918)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.InetAddress.createNSProvider(InetAddress.java:917)
at java.net.InetAddress.<clinit>(InetAddress.java:962)
if the sun.net.spi.nameservice.provider system property is defined.
The current strategy of ThreadLocalRandom relying on other java code for
initialization seems risky.
Using a name service provider other than the default is going to
interact badly here. So is this configured to use the JNDI-DNS provider
("dns,sun") or something else? This provider mechanism has been a source
of many problems, recursive initialization and stack overflow mostly
because any custom provider is likely going to use the network and
resolve host names. It can interact very badly with security when the
provider doesn't have AllPermision because attempts to establish
connections involve security checks that often need to do lookups too.
So I'm curious if there is more to this stack trace to put more context
on the issue. It may be another example to back a suggestion to just
drop the JDK-internal name service provider mechanism. But in general, I
think you are right, it's not good for TLR initialization to trigger
arbitrary code to execute.
-Alan.
