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.h...@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.h...@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.ch...@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.mul...@oracle.com >>>>> <mailto:sean.mul...@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.h...@gmail.com >>>>> <mailto:tom.w.h...@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 >>>>> >>>>> >>>>> >>>>> >>> >> >