Nice one Karl, that's nailed it.
Thanks
-- Rob
Karl Pauls wrote:
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
--
Ascert - Taking systems to the Edge
[EMAIL PROTECTED]
+44 (0)20 7488 3470
www.ascert.com
