felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Felix and WebStart
Date Thu, 05 Jun 2014 14:25:02 GMT
I recall a thread some time back about issues using Felix with WebStart 
as a result of j7u45 security changes.

I'm not sure how far the investigations progressed, but I thought I'd 
report my findings in this area.

This will be rather a long email, but the summary is that with a latest 
trunk build, we are able to get Felix to WebStart.

All is not perfect though, and changes are needed - which I've described 
below. And at present 1 nasty issue remains, which I've also noted 
below. I'll update back if/when we resolve this final issue.

First off, some mods are needed to manifest attributes. We're an Ant 
user, and created a single task to do this for all our JARs in our top 
level build e.g.

    <target name="adjust-manifest-and-sign">
    <jar destfile = "${theFile}" update="true">
    <!-- Add required attributes for Web Start -->
    <attribute name="Permissions" value="all-permissions"/>
    <attribute name="Codebase" value="*"/>
    <attribute name="Application-Name" value="VersaTest"/>

    There are other attributes mentioned in various articles on j7u45
    changes, specifically:

        |Application-Library-Allowable-Codebase: *
        Caller-Allowable-Codebase: *
        Trusted-Library: true
        Trusted-Only: true

    So far I have not observed that any of these are needed or add any
    value to the webstart process at all. The Trusted-Library attribute
    is documented in various places as making matters worse. /Note here
    though our 1 outstanding issue - resolving this may alter our
    opinion on these./

    I'm doubtful that /Application-Name/ is really needed in every JAR
    too - but since it's one Ant task to do all of ours, it's no more
    work and doesn't seem harmful either

The next thing is that your JARs must be signed. I have read that a 
self-signing certificate can still be used if you use the Java Console 
to set a lower Security requirement. I can't report on this, we are 
signing with a full CA issue certificate.

With these mods and JARs signed, the application launches - but we 
always get this message during launch:

It seems almost spurious, since the application does launch. But it does 
remain on-screen for a long time blocking the launch. Pressing OK 
dismisses the dialog, and the application then launches fine despite the 
dialog message. I thought I'd seen a case where the dialog times out on 
it's own, but haven't been able to recreate that.

Doing a stack dump on the Java console actually shows where this dialog 
is coming from (trace below). It's low level in the classloader stack, 
rather nasty place for a dialog to pop up, but where it's happening 
makes perfect sense in terms of trust checking. The part in red is I 
think the section where the checking and problem occurs. What doesn't 
seem to make sense (yet) is why a trusted check would be failing in a 
signed application.  This part we're still trying to isolate.

"Thread-15" #51 prio=6 os_prio=0 tid=0x000000002ba37000 nid=0x228c in 
Object.wait() [0x000000002a89a000]
java.lang.Thread.State: WAITING (on object monitor)
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Unknown Source)
     at com.sun.javaws.ui.JavawsSysRun.delegate(Unknown Source)
     - locked <0x00000005c0f987e8> (a java.lang.Object)
     at com.sun.deploy.util.DeploySysRun.execute(Unknown Source)
     at com.sun.deploy.util.DeploySysRun$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sun.deploy.util.DeploySysRun.executePrivileged(Unknown Source)
*    at com.sun.deploy.ui.UIFactory.showPublisherInfo(Unknown Source)**
**    at 
**    at 
com.sun.deploy.security.SandboxSecurity.showBlockedDialog(Unknown Source)**
**    - locked <0x00000005c141c9e0> (a java.lang.Object)**
**    at 
com.sun.deploy.security.SandboxSecurity.checkRunUntrusted(Unknown Source)**
**    at 
**    - locked <0x00000005c142ebe0> (a 
**    at 
com.sun.deploy.security.SandboxSecurity.isPermissionGranted(Unknown Source)*
     at com.sun.javaws.security.AppPolicy.grantRestrictedAccess(Unknown 
     at com.sun.javaws.security.AppPolicy.addPermissions(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.getTrustedCodeSources(Unknown Source)
com.sun.deploy.security.CPCallbackHandler$ParentCallback.strategy(Unknown Source)
     - locked <0x00000005c0f1f390> (a 
com.sun.deploy.security.DeployURLClassPath$UrlLoader.<init>(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
     at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
     - locked <0x00000005c0f1f160> (a 
     at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown 
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.net.URLClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.net.URLClassLoader.findClass(Unknown Source)
     at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     - locked <0x00000005c0f1dfc0> (a com.sun.jnlp.JNLPClassLoader)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     - locked <0x00000005c0f1df48> (a com.sun.jnlp.JNLPClassLoader)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Unknown Source)
     at org.apache.felix.framework.Felix.init(Felix.java:692)
     at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1011)
     at com.ascert.vt.launch.VtLauncher.launchProfile(VtLauncher.java:983)
     at com.ascert.vt.launch.VtLauncher.start(VtLauncher.java:675)
     at java.lang.Thread.run(Unknown Source)


Ascert - Taking systems to the edge

View raw message