I think I know what is going on. Can you svn up and try again? It should work now...
regards, Karl On Fri, Oct 17, 2008 at 5:15 PM, Rob Walker <[EMAIL PROTECTED]> wrote: > Cool - I'm outa here for week anyhow, so will check back Monday and see if > anyone has clues. > Wondering if it's a JNLP bug of some kind - the Permission test looks pretty > simple, so it implies the "all-permissions" isn't actually getting set. > - R > > Richard S. Hall wrote: >> >> Unfortunately, Karl is the security expert, so I will have to defer to >> him. I hope this is something simple... :-) >> >> -> richard >> >> Rob Walker wrote: >>> >>> Nope - still getting it even after trunk update. >>> >>> Not sure why it happens - our JNLP I think should grant all permissions: >>> >>> <jnlp spec="0.2 1.0" >>> codebase="$$context" >>> href="www/$$name"> >>> <information> >>> <title>VersaTesT - VWINL</title> >>> <vendor>Ascert LLC</vendor> >>> <homepage href="http://www.ascert.com/"/> >>> <description>VersaTest "light" VWIN GUI</description> >>> <description kind="short">VWINL</description> >>> <!-- >>> <icon href="images/swingset2.small.jpg"/> >>> --> >>> <offline-allowed/> >>> </information> >>> <security> >>> <all-permissions/> >>> </security> >>> <resources> >>> <j2se version="1.4+" >>> href="http://java.sun.com/products/autodl/j2se"/> >>> <j2se version="1.4+"/> >>> <jar href="lib/launch.jar" main="true" download="eager"/> >>> <jar href="lib/felix.jar" download="eager"/> >>> <property name="launch.target" value="vwinl"/> >>> <property name="vtmp.home" value="${user.home}/.vtmp"/> >>> <property name="bundle.root" value="$$context"/> >>> </resources> >>> <application-desc >>> main-class="com.ascert.vt.launch.VersionCheckLaunchPanel"/> >>> </jnlp> >>> >>> Which definitely used to work in our past version. >>> >>> Bit of a mystery - looked at the BundleContextImpl code: >>> >>> public String getProperty(String name) >>> { >>> checkValidity(); >>> >>> Object sm = System.getSecurityManager(); >>> >>> if (sm != null) >>> { >>> if (!(Constants.FRAMEWORK_VERSION.equals(name) || >>> Constants.FRAMEWORK_VENDOR.equals(name) || >>> Constants.FRAMEWORK_LANGUAGE.equals(name)|| >>> Constants.FRAMEWORK_OS_NAME.equals(name) || >>> Constants.FRAMEWORK_OS_VERSION.equals(name) || >>> Constants.FRAMEWORK_PROCESSOR.equals(name))) >>> { >>> /Line 82: // /((SecurityManager) sm).checkPermission( >>> new java.util.PropertyPermission(name, "read")); >>> } >>> } >>> >>> return m_felix.getProperty(name); >>> } >>> >>> Not an area I know well - but can't see anything obviously wrong. Seems >>> to follow spec, and in theory we ought to have the requisite permission >>> >>> Will carry on investigating. >>> >>> -- Rob >>> >>> >>> Richard S. Hall wrote: >>>> >>>> Are you using trunk or 1.2.1? >>>> >>>> We just fixed a security-related issue for 1.2.2 (and in trunk) that >>>> address an issue where security was broken. Perhaps this is related, so try >>>> the 1.2.2 release if you aren't on trunk. >>>> >>>> -> richard >>>> >>>> >>>> Rob Walker wrote: >>>>> >>>>> Think we've fallen foul of more recent OSGi security handling - in a >>>>> JNLP launch, we're now seeing: >>>>> >>>>> ERROR: Error starting >>>>> http://localhost:8084/VtWebUi/dsv/ascert/vtmp/lib/vt/propsmgr.jar >>>>> (java.security.AccessControlException: access denied >>>>> (java.util.PropertyPermission system.props.list read)) >>>>> java.security.AccessControlException: access denied >>>>> (java.util.PropertyPermission system.props.list read) >>>>> at java.security.AccessControlContext.checkPermission(Unknown Source) >>>>> at java.security.AccessController.checkPermission(Unknown Source) >>>>> at java.lang.SecurityManager.checkPermission(Unknown Source) >>>>> at >>>>> org.apache.felix.framework.BundleContextImpl.getProperty(BundleContextImpl.java:82) >>>>> >>>>> "system.props.list" is actually one of the properties we pass in into >>>>> Felix via the Map at creation time. >>>>> >>>>> We sign our JARs and didn't trip on this one before - so guessing it's >>>>> something like a default SecurityManager being installed that we need to >>>>> alter or suppress somehow. >>>>> >>>>> Would appreciate some pointers since this is an area I'm not familiar >>>>> with >>>>> >>>>> Regards >>>>> >>>>> -- Rob >>>>> >>>>> >>>>> Ascert - Taking systems to the Edge >>>>> [EMAIL PROTECTED] >>>>> +44 (0)20 7488 3470 >>>>> www.ascert.com >>>>> >>> > > -- > > > Ascert - Taking systems to the Edge > [EMAIL PROTECTED] > +44 (0)20 7488 3470 > www.ascert.com > > -- Karl Pauls [EMAIL PROTECTED]
