[EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed
Michael Pritt
michael.pritt at westringtechnologies.com
Tue Apr 16 07:08:02 UTC 2019
That is a nice fix for windows, however it didn’t solve the problem for us. That fix is for jars that are in the java extension directory and if they are to ensure that they are considered system and would have all permissions. However, you pointing out this piece of code helps me to see more of what is going on. I added some additional debug statements to the code and then ran it. Here is the changes I made and the output:
Code changes:
/**
* Returns true if the CodeSource corresponds to a system jar. That is,
* it's part of the JRE.
*/
private boolean isSystemJar(CodeSource source) {
if (source == null || source.getLocation() == null) {
return false;
}
// anything in JRE/lib/ext is a system jar and has full permissions
String sourceProtocol = source.getLocation().getProtocol();
String sourcePath = source.getLocation().getPath();
if (sourceProtocol.toUpperCase().equals("FILE") &&
sourcePath.startsWith(jreExtDir)) {
return true;
}
// MRP – ADDED the code fix by Christian
String msg = "MRP - CodeSource is not system: " + "(sourcProtocol=" + sourceProtocol + ", location=" + source.getLocation() + ", source=" + source.toString() +
", sourcePath=" + sourcePath + ")\n";
OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, msg);
if (sourceProtocol.equalsIgnoreCase("file"))
{
msg = "MRP - sourceProtocol correct, checking jreExtPath";
final String jreExtPath = jreExtUrl.getPath();
msg += "(jreExtUrl=" + jreExtPath + ", srcPath=" + sourcePath + ")";
OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, msg);
return sourcePath.startsWith(jreExtPath);
}
return false;
}
Output (other output omitted for brevity) – also note that the jreExtUrl is “file:/c:/OpenJDK/jdk-11.0.2/lib/ext”:
CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE found in cacerts (c:\OpenJDK\jdk-11.0.2\lib\security\cacerts)
App already has trusted publisher: true
App already has trusted publisher: true
App already has trusted publisher: true
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/jdk.crypto.cryptoki, source=(jrt:/jdk.crypto.cryptoki <no signer certificates>), sourcePath=/jdk.crypto.cryptoki)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/jdk.crypto.cryptoki, source=(jrt:/jdk.crypto.cryptoki <no signer certificates>), sourcePath=/jdk.crypto.cryptoki)
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.xml.crypto, source=(jrt:/java.xml.crypto <no signer certificates>), sourcePath=/java.xml.crypto)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.xml.crypto, source=(jrt:/java.xml.crypto <no signer certificates>), sourcePath=/java.xml.crypto)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.xml.crypto, source=(jrt:/java.xml.crypto <no signer certificates>), sourcePath=/java.xml.crypto)
Denying permission: ("java.security.SecurityPermission" "putProviderProperty.XMLDSig")
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.smartcardio, source=(jrt:/java.smartcardio <no signer certificates>), sourcePath=/java.smartcardio)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.smartcardio, source=(jrt:/java.smartcardio <no signer certificates>), sourcePath=/java.smartcardio)
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/jdk.security.jgss, source=(jrt:/jdk.security.jgss <no signer certificates>), sourcePath=/jdk.security.jgss)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/jdk.security.jgss, source=(jrt:/jdk.security.jgss <no signer certificates>), sourcePath=/jdk.security.jgss)
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.security.jgss, source=(jrt:/java.security.jgss <no signer certificates>), sourcePath=/java.security.jgss)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.security.jgss, source=(jrt:/java.security.jgss <no signer certificates>), sourcePath=/java.security.jgss)
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/jdk.crypto.mscapi, source=(jrt:/jdk.crypto.mscapi <no signer certificates>), sourcePath=/jdk.crypto.mscapi)
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/jdk.crypto.mscapi, source=(jrt:/jdk.crypto.mscapi <no signer certificates>), sourcePath=/jdk.crypto.mscapi)
Denying permission: ("java.lang.RuntimePermission" "loadLibrary.sunmscapi")
Class-Path attribute cleared for C:\Users\michael.pritt\.cache\icedtea-web\cache\307\http\dev-wbm101\8080\icedtea\wildfly-client-all-15.0.1.Final.jar
Class-Path attribute cleared for C:\Users\michael.pritt\.cache\icedtea-web\cache\219\http\dev-wbm101\8080\icedtea\wildfly-elytron-1.7.0.Final.jar
MRP - CodeSource is not system: (sourcProtocol=jrt, location=jrt:/java.security.jgss, source=(jrt:/java.security.jgss <no signer certificates>), sourcePath=/java.security.jgss)
Denying permission: ("java.util.PropertyPermission" "sun.security.jgss.native" "read")
(End of output)
I believe that this output tells me that the standard java security stuff is not being flagged properly. Why? Because why does the code ask if the codesource is a system jar for stuff like “jrt:/java.security.jgss”, or even “jrt:/jdk.crypto.mscapi”? Shouldn’t those code bases already be flagged as system? If I were to change the sourceProtocol string compare from “file” to “jrt”, our application runs correctly with icedtea-web.
I’ve also put a breakpoint when permissions are being denied and looked up the call stack…I believe the default.policy file for the jdk is perhaps ignored or not handled properly (i.e. the Open JDK 11.0.2/lib/security/default.policy). In this case with the breakpoint set, I find that the GSS module (java/sun/jgss) GSSManagerImpl is requesting permission for “sun.security.jgss.native”. In looking at the default.policy file that module definitely has the all permissions set for its codebase.
grant codeBase "jrt:/jdk.security.jgss" {
permission java.security.AllPermission;
};
So is this a bug?
Thanks for all the suggestions and help!!!
From: Christian Svedin [mailto:christian.svedin at idainfront.se]
Sent: Monday, April 15, 2019 5:33 AM
To: Michael Pritt <michael.pritt at westringtechnologies.com>; distro-pkg-dev at openjdk.java.net; jvanek at redhat.com
Subject: Re: [EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed
Cool, looks like it's the same thing as I'm talking about. I won't create a PR for it then :)
/ Christian
On Mon, 2019-04-15 at 13:07 +0200, Jiri Vanek wrote:
Isnt this https://github.com/AdoptOpenJDK/icedtea-web/pull/9
fixing the same?
J.
On 4/15/19 7:03 AM, Christian Svedin wrote:
There is a bug in the isSystemJar method in JNLPPolicy that makes it not recognize system-jars in
windows. Looks like that might be what you are having a problem with.
I fixed this in a local branch of ITW but haven't gotten around to creating a pull-request yet.
This is how I fixed it but I guess that are more possible approaches
diff --git a/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java
b/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java
index 8baacb19..69174f76 100644
--- a/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java
@@ -55,6 +55,8 @@ public class JNLPPolicy extends Policy {
/** the user-level policy for jnlps */
private Policy userJnlpPolicy = null;
+ private URL jreExtUrl;
+
protected JNLPPolicy() {
shellSource = JNLPPolicy.class.getProtectionDomain().getCodeSource();
systemSource = Policy.class.getProtectionDomain().getCodeSource();
@@ -65,6 +67,15 @@ public class JNLPPolicy extends Policy {
String jre = System.getProperty("java.home");
jreExtDir = jre + File.separator + "lib" + File.separator + "ext";
+ try
+ {
+ jreExtUrl = new File(jreExtDir).toURI().toURL();
+ }
+ catch (MalformedURLException e)
+ {
+ OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e);
+ throw new RuntimeException("Failed to create url for: " + jreExtDir, e);
+ }
}
/**
@@ -157,9 +168,10 @@ public class JNLPPolicy extends Policy {
// anything in JRE/lib/ext is a system jar and has full permissions
String sourceProtocol = source.getLocation().getProtocol();
String sourcePath = source.getLocation().getPath();
- if (sourceProtocol.toUpperCase().equals("FILE") &&
- sourcePath.startsWith(jreExtDir)) {
- return true;
+
+ if (sourceProtocol.equalsIgnoreCase("file")) {
+ final String jreExtPath = jreExtUrl.getPath();
+ return sourcePath.startsWith(jreExtPath);
}
return false;
On Fri, 2019-04-12 at 20:16 +0000, Michael Pritt wrote:
Still investigating why our jnlp isn't working with icedtea-web and have done some other tests to see what might be the problem...hoping some of this might ring a bell or point me into a good direction.
Using an earlier version of our application that builds against java 8 did the following
Test #1: Ran java 1.8.0_161 javaws against our application .jnlp and it works.
Test #2: Ran icedtea-web 1.7.1 javaws against the same application .jnlp and it fails...
Test #3: Ran icedtea-web 1.7.1 against our application (updated to to work with java 11)
From this test it seems similar problems in handling the sunmscapi.jar....just different output. Could it be the same issue, and if so why?
I've debugged icedtea and all the jars are signed, the signature hash matches, each jar is requesting all permissions, the jnlp is requesting all permissions. When I do change the java.policy file for the codebase of the jnlp the application does work. My main issue is we've not had to mess with the java.policy file before when using java webstart. I don't think we should need to do that when using icedtea-web. Here is some additional data from tests #2 and #3.
Here is some of the output for test #3: (icedtea against java 11)
Denying permission: ("java.lang.RuntimePermission" "loadLibrary.sunmscapi")
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Denying permission: ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
Here is some of the output for Test#2: (icedtea-web against java 8)
Application is trying to get permissions for file:/C:/Program%20Files/Java/jre1.8.0_162/lib/ext/sunmscapi.jar, which was not added by standard way. Trying to download and verify!
Connecting file:/C:/Program%20Files/Java/jre1.8.0_162/lib/ext/sunmscapi.jar
done file:/C:/Program%20Files/Java/jre1.8.0_162/lib/ext/sunmscapi.jar
Disconnecting sun.net.www.protocol.file.FileURLConnection:file:/C:/Program%20Files/Java/jre1.8.0_162/lib/ext/sunmscapi.jar
Error: No security instance for file:/C:/Program%20Files/Java/jre1.8.0_162/lib/ext/sunmscapi.jar. The application may have trouble continuing
java.lang.NullPointerException: Code source security was null
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:1231)
at net.sourceforge.jnlp.runtime.JNLPPolicy.getPermissions(JNLPPolicy.java:88)
at net.sourceforge.jnlp.runtime.JNLPPolicy.implies(JNLPPolicy.java:199)
at java.security.ProtectionDomain.implies(Unknown Source)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkRead(Unknown Source)
at java.io.File.exists(Unknown Source)
at net.sourceforge.jnlp.cache.ResourceTracker.getCacheFile(ResourceTracker.java:356)
at net.sourceforge.jnlp.cache.ResourceTracker.getCacheURL(ResourceTracker.java:317)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.addNewJar(JNLPClassLoader.java:1689)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.addNewJar(JNLPClassLoader.java:1656)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getCodeSourceSecurity(JNLPClassLoader.java:2047)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:1230)
at net.sourceforge.jnlp.runtime.JNLPPolicy.getPermissions(JNLPPolicy.java:88)
at net.sourceforge.jnlp.runtime.JNLPPolicy.implies(JNLPPolicy.java:199)
at java.security.ProtectionDomain.implies(Unknown Source)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.mscapi.SunMSCAPI$1.run(SunMSCAPI.java:52)
at sun.security.mscapi.SunMSCAPI$1.run(SunMSCAPI.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.mscapi.SunMSCAPI.<clinit>(SunMSCAPI.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.loadAll(Unknown Source)
at sun.security.jca.ProviderList.removeInvalid(Unknown Source)
at sun.security.jca.Providers.getFullProviderList(Unknown Source)
at java.security.Security.getProviders(Unknown Source)
at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121)
at org.xnio.sasl.SaslUtils.getSaslClientFactories(SaslUtils.java:98)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:405)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
java.lang.NullPointerException: Code source security was null
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:1231)
at net.sourceforge.jnlp.runtime.JNLPPolicy.getPermissions(JNLPPolicy.java:88)
at net.sourceforge.jnlp.runtime.JNLPPolicy.implies(JNLPPolicy.java:199)
at java.security.ProtectionDomain.implies(Unknown Source)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkRead(Unknown Source)
at java.io.File.exists(Unknown Source)
at net.sourceforge.jnlp.cache.ResourceTracker.getCacheFile(ResourceTracker.java:356)
at net.sourceforge.jnlp.cache.ResourceTracker.getCacheURL(ResourceTracker.java:317)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.addNewJar(JNLPClassLoader.java:1689)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.addNewJar(JNLPClassLoader.java:1656)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getCodeSourceSecurity(JNLPClassLoader.java:2047)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:1230)
at net.sourceforge.jnlp.runtime.JNLPPolicy.getPermissions(JNLPPolicy.java:88)
at net.sourceforge.jnlp.runtime.JNLPPolicy.implies(JNLPPolicy.java:199)
at java.security.ProtectionDomain.implies(Unknown Source)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.mscapi.SunMSCAPI$1.run(SunMSCAPI.java:52)
at sun.security.mscapi.SunMSCAPI$1.run(SunMSCAPI.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.mscapi.SunMSCAPI.<clinit>(SunMSCAPI.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.loadAll(Unknown Source)
at sun.security.jca.ProviderList.removeInvalid(Unknown Source)
at sun.security.jca.Providers.getFullProviderList(Unknown Source)
at java.security.Security.getProviders(Unknown Source)
at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121)
at org.xnio.sasl.SaslUtils.getSaslClientFactories(SaslUtils.java:98)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:405)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
Error: No security instance for file:/C:/Program%20Files/Java/jre1.8.0_162/lib/ext/sunmscapi.jar. The application may have trouble continuing
java.lang.NullPointerException: Code source security was null
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:1231)
at net.sourceforge.jnlp.runtime.JNLPPolicy.getPermissions(JNLPPolicy.java:88)
at net.sourceforge.jnlp.runtime.JNLPPolicy.implies(JNLPPolicy.java:199)
at java.security.ProtectionDomain.implies(Unknown Source)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:292)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.mscapi.SunMSCAPI$1.run(SunMSCAPI.java:52)
at sun.security.mscapi.SunMSCAPI$1.run(SunMSCAPI.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.mscapi.SunMSCAPI.<clinit>(SunMSCAPI.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at sun.security.jca.ProviderConfig$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jca.ProviderConfig.doLoadProvider(Unknown Source)
at sun.security.jca.ProviderConfig.getProvider(Unknown Source)
at sun.security.jca.ProviderList.loadAll(Unknown Source)
at sun.security.jca.ProviderList.removeInvalid(Unknown Source)
at sun.security.jca.Providers.getFullProviderList(Unknown Source)
at java.security.Security.getProviders(Unknown Source)
at org.xnio.sasl.SaslUtils.getFactories(SaslUtils.java:121)
at org.xnio.sasl.SaslUtils.getSaslClientFactories(SaslUtils.java:98)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:405)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
-----Original Message-----
From: Jiri Vanek [mailto:jvanek at redhat.com<mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com<mailto:jvanek at redhat.com>>]
Sent: Tuesday, April 9, 2019 4:11 AM
To: Michael Pritt <michael.pritt at westringtechnologies.com<mailto:michael.pritt at westringtechnologies.com> <mailto:michael.pritt at westringtechnologies.com<mailto:michael.pritt at westringtechnologies.com>>>; distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net> <mailto:distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net>>
Subject: Re: [EXTERNAL] Re: IcedTea-Web javaws is running the jnlp app sandboxed
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<mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com<mailto:jvanek at redhat.com>>>;
'distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net> <mailto:distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net>>' <distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net> <mailto:distro-pkg-dev at openjdk.java.net<mailto: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<mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com<mailto:jvanek at redhat.com>>>; distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net> <mailto:distro-pkg-dev at openjdk.java.net<mailto: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<mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com<mailto:jvanek at redhat.com>>]
Sent: Monday, April 8, 2019 2:46 AM
To: Michael Pritt <michael.pritt at westringtechnologies.com<mailto:michael.pritt at westringtechnologies.com> <mailto:michael.pritt at westringtechnologies.com<mailto:michael.pritt at westringtechnologies.com>>>;
distro-pkg-dev at openjdk.java.net<mailto:distro-pkg-dev at openjdk.java.net> <mailto:distro-pkg-dev at openjdk.java.net<mailto: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<mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com<mailto:jvanek at redhat.com>> M: +420775390109
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com<mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com<mailto:jvanek at redhat.com>> M: +420775390109
--
Ida Infront
Christian Svedin
Systemutvecklare
Ida Infront AB | Box 576 | SE-581 07 Linköping | Sweden
mobile 0702 09 22 40 | direct 013 37 37 47
e-mail christian.svedin at idainfront.se<mailto:christian.svedin at idainfront.se> | web www.idainfront.se<http://www.idainfront.se>
--
Ida Infront
Christian Svedin
Systemutvecklare
Ida Infront AB | Box 576 | SE-581 07 Linköping | Sweden
mobile 0702 09 22 40 | direct 013 37 37 47
e-mail christian.svedin at idainfront.se<mailto:christian.svedin at idainfront.se> | web www.idainfront.se<http://www.idainfront.se>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190416/77019133/attachment-0001.html>
More information about the distro-pkg-dev
mailing list