StackOverflowError - Java 9 Build 181
Tom Hood
tom.w.hood at gmail.com
Wed Sep 20 21:14:33 UTC 2017
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(SecurityManager.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(SecurityManager.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/0a5aceba/attachment.htm>
More information about the security-dev
mailing list