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