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

Michael Pritt michael.pritt at westringtechnologies.com
Mon Apr 8 17:50:23 UTC 2019


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


More information about the distro-pkg-dev mailing list