[EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed

Jiri Vanek jvanek at redhat.com
Tue Apr 9 10:11:26 UTC 2019 

On 4/9/19 1:58 AM, Michael Pritt wrote:
> Just so you know, I ran the windows MSI installer for 1.8.  Same issues as for 1.7.2 as described earlier.  FYI I tried using the zip file for 1.8 using the link: 	http://icedtea.wildebeest.org/download/icedtea-web-binaries/1.8/windows/icedtea-web-1.8.win.bin.zip
> It does not work because the zip file seems to be corrupted.  

zip works for me. have you checked hashes and signatures?

> 
> I've downloaded the master.  If I'm understanding it right, the javaws portion is totally java and should be able to only focus on that portion.  Is it the Boot.java main class that needs to be run with the jnlp file as the argument?  Is there some instructions somewhere that can help me get going so I can debug this issue?  I've tried running it but it's hanging at the moment.  Are their some environment vars, etc? 

Master is now very very broken.   Guys from karakun are making really a lot of changes.
For debuging, yes,  boot.java is what is taking jnlp as argument. You are on correct way!  Generally
you should nt have issues to debug that - any ide or remt edebugger will do. Teh only trick may be
the bootclasapth. I got to habit, when debugging from ide, to put the same classes also to
bootclasapth. Feel free to ping for any more info.
The main source shoudl be http://icedtea.classpath.org/wiki/IcedTea-Web


ITW and ORacle Javaws are doing a lot of things differently.  However you noted important part -
that you movced to jdk11. Some legacy (even signing) security algortihms were removed. Can that be
cause? Aleso jdk11 have very serious and know bug in AWT thread.  Its fix is going to be log run.
Maybe it is it? This bug shold not be in jdk12. Worthy to try?
> 
> So anything would be helpful here, as my group is investigating two options for a javaws replacement:  GetDown or IcedTea-Web.  My preference is IcedTea-Web if I can get it to work.

Thank you very much for support!
 Crossing fingers,
  J.
> 
> Thanks
> 
> -----Original Message-----
> From: Michael Pritt 
> Sent: Monday, April 8, 2019 11:50 AM
> To: 'Jiri Vanek' <jvanek at redhat.com>; 'distro-pkg-dev at openjdk.java.net' <distro-pkg-dev at openjdk.java.net>
> Subject: RE: [EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed
> 
> Perhaps I should download the master as it currently stands on github and try to run/debug the code to see what is actually happening.  It's just weird to me to have this work with the original javaws and not with icedtea-web.
> 
> -----Original Message-----
> From: Michael Pritt
> Sent: Monday, April 8, 2019 10:20 AM
> To: 'Jiri Vanek' <jvanek at redhat.com>; distro-pkg-dev at openjdk.java.net
> Subject: RE: [EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed
> 
> This application has been running for some time now (several years) using Java 8 and its associated web start.  We have just recently started to migrate this application to Java 11.  We have not changed our jar signing process at all during this migration.  So I believe the signature to be valid.  I'm wondering if IcedTea-Web is doing something or recognizing something differently than what java web start has been doing.
> 
> -----Original Message-----
> From: Jiri Vanek [mailto:jvanek at redhat.com]
> Sent: Monday, April 8, 2019 2:46 AM
> To: Michael Pritt <michael.pritt at westringtechnologies.com>; distro-pkg-dev at openjdk.java.net
> Subject: [EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed
> 
> Is it possible that the signature is invalid?
> You should get better warning in this case, but it could get lost somewhere in the process - you should get application is requesting permissions, but signature is broken".
> 
> 
> On 4/6/19 4:31 AM, mpritt wrote:
>> I'm not sure why my application seems to always run being sandboxed 
>> (or so it seems), when running with IcedTea-Web's javaws.  I'm running 
>> in a Windows environment with the IcedTea-Web version 1.7.2 and the java OpenJDK 11.0.2.
>>
>> Note that I can run the app successfully using the -nosecurity option.
>>
>> All the jars are signed and each jar has in it's manifest the following:
>>
>> Permissions: all-permissions
>> Codebase: *
>> Trusted-Library: true
>> Application-Library-Allowable-Codebase: *
>> Caller-Allowable-Codebase: *
>>
>> The .jnlp file has requested all permissions as well: 
>>   
>>   <security>
>>     <all-permissions/>
>>   </security>
>>
>> With the debugging option turned on I can see that the certificate is 
>> accepted, and that the jars are being recognized as signed.  When the 
>> app first gets downloaded,  the dialog pops up requesting permission 
>> to run with unrestricted access and the I've selected the "run"
>> button.  However the app seems to runs in sandbox mode.  (I've also 
>> cleared out the cache and then manually selected all security options 
>> as well to try to run it any differently but to no avail).
>>
>> I've also tried creating a java.policy file under the 
>> .config/icedtea-web/security directory and have it allow all 
>> permissions (I don't believe I should have to do this anyway) by putting into the file:
>>
>> grant {
>>   permission java.lang.AllPermission;
>> };
>>
>>
>> With debugging turned on I see that certain permissions are not being 
>> allowed.  I see the following statements:
>>
>> Denying permission: ("java.lang.RuntimePermission"
>> "accessClassInPackage.sun.security.util")
>> Denying permission: ("java.security.SecurityPermission"
>> "putProviderProperty.XMLDSig")
>> Denying permission: ("java.lang.RuntimePermission"
>> "accessClassInPackage.sun.security.krb5")
>>
>> I do see the following file permission given (i.e. Permission added:
>> ("java.io.FilePermission"
>> "...\.cache\icedtea-web\cache\352\...\persistence-api-1.0.jar" 
>> "read"))
>>
>>
>> Application starts up but fails because of security exceptions from 
>> the login attempt (i.e
>> javax.security.auth.login.LoginException: Security Exception
>> 	at
>> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:805)
>> 	at
>> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
>> 	at
>> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
>> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
>> 	at
>> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
>> 	at
>> java.base/javax.security.auth.login.LoginContext.login(LoginContext.ja
>> va:574)
>> )
>>
>> Like I mentioned before, the application works just fine when the 
>> -nosecurity option is added.
>>
>> Does anyone have any idea as to what might be the problem?
>>
>> Thanks,
>>
>>
>>
>> --
>> Sent from: 
>> http://openjdk.5641.n7.nabble.com/OpenJDK-Distribution-specific-Packag
>> ing-f25548.html
>>
> 
> 
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jvanek at redhat.com    M: +420775390109
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com    M: +420775390109

More information about the distro-pkg-dev mailing list