StackOverflowError - Java 9 Build 181

Tom Hood tom.w.hood at gmail.com
Wed Sep 20 21:49:29 UTC 2017


Sean,

Rather than add those lines in my JDK installation, I'm going to add them
in my JRE installation, specifically:  C:\Program
Files\Java\jre9b181\lib\security\default.policy.  If this is different than
what you intended, please let me know.  The infinite recursion is happening
when running with the JRE.  I haven't tried running with the JDK
installation.

-- Tom

On Wed, Sep 20, 2017 at 2:17 PM, Tom Hood <tom.w.hood at gmail.com> wrote:

> In case useful, our jnlp file also contains this:
> <security>
>   <all-permissions/>
> </security>
>
>
> On Wed, Sep 20, 2017 at 2:14 PM, Tom Hood <tom.w.hood at gmail.com> wrote:
>
>> Sean,
>>
>> I'll add those lines to the lib/security/default.policy file as you
>> suggested.  I left the app running overnight and came in this morning and
>> it was stuck in the infinite recursion loop again.  I'll leave it running
>> tonight as well with the default.policy change.
>>
>> How do I set java.security.debug=all within the jnlp?  I tried several
>> things, but none worked.
>>
>> <j2se version="1.9+" initial-heap-size="32m" max-heap-size="3072m"
>>   java-vm-args="*-Djava.security.debug=all* --add-modules=java.corba
>> --add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
>> --add-exports=java.desktop/sun.swing=ALL-UNNAMED
>> --add-exports=java.desktop/sun.awt.shell=ALL-UNNAMED
>> --add-opens=java.base/java.lang=ALL-UNNAMED
>> --add-exports=java.desktop/sun.awt.image=ALL-UNNAMED"/>
>>
>> Then I tried setting it as a property in the jnlp:
>>
>> <property name="jnlp.*java.security.**debug*" value="all"/>
>>
>> I also tried removing the jnlp prefix from the property name:
>>
>> <property name="*java.security.debug*" value="all"/>
>>
>> Then I tried setting it at the start of main with
>> Security.setProperty("java.security.debug", "all") as well as
>> System.setProperty("java.security.debug", "all").  No luck.
>>
>> Then I tried wrapping javaws in a windows batch file with the following
>> line and selecting the batch file when firefox asks for the program to open
>> the jnlp with:
>>
>> C:\"Program Files"\Java\jre9b181\bin\javaws -J*-Djava.security.debug=all*
>> %1
>>
>> which also didn't work.
>>
>> -- Tom
>>
>>
>> On Wed, Sep 20, 2017 at 12:56 PM, mandy chung <mandy.chung at oracle.com>
>> wrote:
>>
>>> FYI.  jdk.javaws is granted with AllPermissions in
>>> conf/security/javaws.policy.   Maybe javaws.policy is not augmented to the
>>> security policy at runtime?
>>>
>>> Mandy
>>>
>>>
>>> On 9/20/17 12:45 PM, Sean Mullan wrote:
>>>
>>>> Tom,
>>>>
>>>> Try adding the following lines to the lib/security/default.policy file
>>>> in your JDK installation:
>>>>
>>>> grant codeBase "jrt:/jdk.javaws" {
>>>>     permission java.security.AllPermission;
>>>> };
>>>>
>>>> I have a hunch that permissions are not being granted to the jdk.javaws
>>>> module before it needs them. If that fixes the issue (or you don't see it
>>>> for a few days), I'll followup and file a bug.
>>>>
>>>> Thanks,
>>>> Sean
>>>>
>>>> On 9/19/17 5:55 PM, Tom Hood wrote:
>>>>
>>>>> No luck so far reproducing this problem. The two times it happened to
>>>>> me yesterday have both been with Java 9 build 181 and the application has
>>>>> been idle for awhile. I login to our application, execute various features
>>>>> of the application, go to a meeting, return, and then see the java console
>>>>> repeatedly displaying the stack overflow exception. Maybe meetings are bad
>>>>> for Java 9? :-)  I think there are some background threads in our
>>>>> application that are waking up periodically and doing "stuff".  I don't
>>>>> know what that "stuff" is yet, but that would be my guess at where I will
>>>>> find the code that triggered the overflow.
>>>>>
>>>>> Assuming I can get our application to the point where I can reproduce
>>>>> the stack overflow, are there particular Java 9 builds that made
>>>>> significant changes to security-relevant code that you'd like me to try?
>>>>>
>>>>> Keep in mind that our app runs on a network not connected to the
>>>>> internet.  As it is, I manually typed in the stack trace, so if there's a
>>>>> lot of output I'll have to print it and go through an approval process to
>>>>> show it to you via a scanned pdf.  I will continue testing of our app with
>>>>> the security debug turned on so that I'll have the output if it happens
>>>>> again.  I also have the logging and tracing enabled in the java control
>>>>> panel.
>>>>>
>>>>> -- Tom
>>>>>
>>>>>
>>>>> On Tue, Sep 19, 2017 at 12:13 PM, Sean Mullan <sean.mullan at oracle.com
>>>>> <mailto:sean.mullan at oracle.com>> wrote:
>>>>>
>>>>>     Cross-posting to security-dev as this is more relevant to that list
>>>>>     and bcc-ing core-libs-dev.
>>>>>
>>>>>     I think this might be an issue with the JavaWebStart
>>>>> SecurityManager
>>>>>     not being granted the proper permissions. It is possible that the
>>>>>     deployment policy files are not being loaded or there is some other
>>>>>     subtle bootstrapping issue. It should not result in a recursive
>>>>> loop
>>>>>     of course, but there may be a workaround.
>>>>>
>>>>>     In the meantime, can you send me more information, preferably a
>>>>> test
>>>>>     case and a log file with -Djava.security.debug=all enabled? (The
>>>>>     latter will help analyze the recursion and see what security checks
>>>>>     are failing and for which ProtectionDomains). Also, have you tested
>>>>>     this on builds earlier than b181?
>>>>>
>>>>>     Thanks,
>>>>>     Sean
>>>>>
>>>>>     On 9/19/17 2:53 PM, Tom Hood wrote:
>>>>>
>>>>>         I should add that we have not modified or overridden any policy
>>>>>         files.
>>>>>         Also, we are not using a custom security manager.
>>>>>
>>>>>         On Tue, Sep 19, 2017 at 11:52 AM, Tom Hood <
>>>>> tom.w.hood at gmail.com
>>>>>         <mailto:tom.w.hood at gmail.com>> wrote:
>>>>>
>>>>>             Hi,
>>>>>
>>>>>             I hit an infinite recursion loop probably related to
>>>>>             PolicyFile that
>>>>>             exists in Java 9 build 181 for windows 64-bit.  It might be
>>>>>             related to
>>>>>             JDK-8077418
>>>>>             <https://bugs.openjdk.java.net/browse/JDK-8077418
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8077418>>
>>>>>
>>>>>
>>>>>             I haven't tracked down what is causing our webstart app to
>>>>>             hit this
>>>>>             problem yet, but I thought I would let you know sooner than
>>>>>             later.  Also,
>>>>>             it probably is not a problem for our particular application
>>>>>             as I should be
>>>>>             able to set the security manager to null which I think/hope
>>>>>             will bypass
>>>>>             this issue.  I will try today to reproduce it in our app so
>>>>>             I can confirm
>>>>>             if setting security manager to null will work for us.
>>>>>
>>>>>             The stack looks like the following: (with many repeat
>>>>> stacks
>>>>>             omitted)
>>>>>
>>>>>             Exception in thread "AWT-EventQueue-2"
>>>>>             java.lang.StackOverflowError
>>>>>             at
>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>             Method)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.getPermissions(Po
>>>>>             licyFile.java:1135)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.getPermissions(Po
>>>>>             licyFile.java:1082)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.implies(PolicyFil
>>>>>             e.java:1038)
>>>>>             at java.base/java.security.provid
>>>>> er.ProtectionDomain.implies(Pr
>>>>>             otectionDomain.java:323)
>>>>>             at java.base/java.security.provid
>>>>> er.ProtectionDomain.impliesWit
>>>>>             hAltFilePerm(ProtectionDomain.java:355)
>>>>>             at java.base/java.security.provid
>>>>> er.AccessControlContext.checkP
>>>>>             ermission(AccessControlContext.java:450)
>>>>>             at java.base/java.security.provid
>>>>> er.AccessController.checkPermi
>>>>>             ssion(AccessController.java:895)
>>>>>             at java.base/java.lang.SecurityMa
>>>>> nager.checkPermission(Security
>>>>>             Manager.java:558)
>>>>>             at jdk.javaws/com.sun.javaws.secu
>>>>> rity.JavaWebStartSecurity.chec
>>>>>             kPermission(JavaWebStartSecurity.java:237)
>>>>>             at
>>>>> java.base/java.lang.SecurityManager.checkRead(SecurityManage
>>>>> r.java:897)
>>>>>             at java.base/java.io.File.isDirectory(File.java:845)
>>>>>             at
>>>>> java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.canonicalizeCodeb
>>>>>             ase(PolicyFile.java:1665)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.access$700(Policy
>>>>>             File.java:263)
>>>>>             at
>>>>> java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139)
>>>>>             at
>>>>> java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136)
>>>>>             **** and again ****
>>>>>             at
>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>             Method)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.getPermissions(Po
>>>>>             licyFile.java:1135)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.getPermissions(Po
>>>>>             licyFile.java:1082)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.implies(PolicyFil
>>>>>             e.java:1038)
>>>>>             at java.base/java.security.provid
>>>>> er.ProtectionDomain.implies(Pr
>>>>>             otectionDomain.java:323)
>>>>>             at java.base/java.security.provid
>>>>> er.ProtectionDomain.impliesWit
>>>>>             hAltFilePerm(ProtectionDomain.java:355)
>>>>>             at java.base/java.security.provid
>>>>> er.AccessControlContext.checkP
>>>>>             ermission(AccessControlContext.java:450)
>>>>>             at java.base/java.security.provid
>>>>> er.AccessController.checkPermi
>>>>>             ssion(AccessController.java:895)
>>>>>             at java.base/java.lang.SecurityMa
>>>>> nager.checkPermission(Security
>>>>>             Manager.java:558)
>>>>>             at jdk.javaws/com.sun.javaws.secu
>>>>> rity.JavaWebStartSecurity.chec
>>>>>             kPermission(JavaWebStartSecurity.java:237)
>>>>>             at
>>>>> java.base/java.lang.SecurityManager.checkRead(SecurityManage
>>>>> r.java:897)
>>>>>             at java.base/java.io.File.isDirectory(File.java:845)
>>>>>             at
>>>>> java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.canonicalizeCodeb
>>>>>             ase(PolicyFile.java:1665)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.access$700(Policy
>>>>>             File.java:263)
>>>>>             at
>>>>> java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139)
>>>>>             at
>>>>> java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136)
>>>>>             **** above lines start the stack that repeats until
>>>>> overflow
>>>>>             ****
>>>>>             at
>>>>> java.base/java.security.AccessController.doPrivileged(Native
>>>>>             Method)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.getPermissions(Po
>>>>>             licyFile.java:1135)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.getPermissions(Po
>>>>>             licyFile.java:1082)
>>>>>             at java.base/sun.security.provide
>>>>> r.PolicyFile.implies(PolicyFil
>>>>>             e.java:1038)
>>>>>
>>>>>             -- Tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170920/fbee9c69/attachment.htm>


More information about the security-dev mailing list