You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rob Walker <ro...@ascert.com> on 2008/10/17 15:37:14 UTC
New Felix throwing access exception
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
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: New Felix throwing access exception
Posted by Rob Walker <ro...@ascert.com>.
I'm on trunk - but I'll do an update just in case I missed the fix.
Cheers
-- 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
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: New Felix throwing access exception
Posted by Rob Walker <ro...@ascert.com>.
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 <ro...@ascert.com> 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
>>>>>> robw@ascert.com
>>>>>> +44 (0)20 7488 3470
>>>>>> www.ascert.com
>>>>>>
>>>>>>
>> --
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
>>
>
>
>
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: New Felix throwing access exception
Posted by Karl Pauls <ka...@gmail.com>.
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 <ro...@ascert.com> 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
>>>>> robw@ascert.com
>>>>> +44 (0)20 7488 3470
>>>>> www.ascert.com
>>>>>
>>>
>
> --
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: New Felix throwing access exception
Posted by Rob Walker <ro...@ascert.com>.
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
>>>> robw@ascert.com
>>>> +44 (0)20 7488 3470
>>>> www.ascert.com
>>>>
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: New Felix throwing access exception
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>>> robw@ascert.com
>>> +44 (0)20 7488 3470
>>> www.ascert.com
>>>
>
Re: New Felix throwing access exception
Posted by Rob Walker <ro...@ascert.com>.
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
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: New Felix throwing access exception
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>