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(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
>>>>
>>>>
>>>>
>>>>
>>
>
