On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman <alan.bate...@oracle.com>
wrote:
> 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.
The way we are actually seeing this is:
- there are jdk8 jtreg tests that set the sun.net.spi.nameservice.provider
property. Grepping:
./java/net/Inet4Address/textToNumericFormat.java
./java/net/URLPermission/nstest/lookup.sh
./sun/net/InetAddress/nameservice/dns/cname.sh
./sun/net/InetAddress/nameservice/deadlock/Hang.java
./sun/net/InetAddress/nameservice/chaining/Providers.java
./sun/net/InetAddress/nameservice/simple/DefaultCaching.java
./sun/net/InetAddress/nameservice/simple/CacheTest.java
./sun/security/krb5/auto/KDC.java
./sun/security/krb5/canonicalize/Test.java
- we have local modifications to classloading that happen to use TLR
via ConcurrentSkipListMap - a "reasonable" thing to do. Probably the
simplest way to provoke a failure is to try to use a TLR from e.g.
URLClassPath.
In general, any core library boot class should try hard to avoid
loading/invoking code from the user's classpath.
> 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.
>
