Can you open a bug against Equinox?  I would like to get to the bottom of 
why the protection domain is not granting all permissions when used with 
ACC

The projection domain used to define classes from bundles should only be 
configurable by one of the framework's permission admin services.  If you 
have not done any configuration with these services then the default is 
AllPermissions for all bundles.  I suspect when passing the domains to the 
ACC constructor it is trying to extract the permissions out of the domain, 
but that must be failing somehow.

At any rate, you should never need to use a permission policy file to 
grant permissions to osgi bundles.  The permissions are assigned to bundle 
classes only though the framework's permission admin services.

Tom





From:   Derek Baum <[email protected]>
To:     Equinox development mailing list <[email protected]>
Date:   05/19/2016 04:30 PM
Subject:        Re: [equinox-dev] security exceptions using Felix config 
admin   withEquinox
Sent by:        [email protected]



I'm not using anyPermission Admin Service; the SecurityManager is set 
using:

if (System.getSecurityManager() == null) {
    System.setSecurityManager(new SecurityManager());
}

with the java.security.policy System property pointing to the security 
policy file.

I guess if I switched to using Conditional Permission Admin instead, then 
this problem wouldn’t occur,
because the Equinox ProtectionDomain would be constructed with explicit 
Permissions from Permission Admin?


I only set a Security Manager, because it is required by RMI; I have not 
defined a fine-grained security policy - it grants AllPermission,
so I don’t really want to run and configure Permission Admin just to make 
this work on Equinox.

I’m also exploring using the Equinox config admin, as this doesn’t create 
a new AccessControlContext using the classes ProtectionDomain,
so avoids the issue.

BJ’s suggestion of changing Felix config admin to use the one-arg 
doPrivileged() method seems reasonable and would also resolve the issue.

—
Derek



On 19 May 2016, at 13:52, Thomas Watson <[email protected]> wrote:

When you say security policy, I assume you mean the one you set through 
one of the framework's permission admin service?  And how are you setting 
the security manager?

Tom





From:        Derek Baum <[email protected]>
To:        [email protected]
Date:        05/18/2016 02:16 PM
Subject:        Re: [equinox-dev] security exceptions using Felix config 
admin with        Equinox
Sent by:        [email protected]



Hi,

I’ve also posted this to the Felix dev list, as the problem occurs when 
using Felix config admin with Equinox runtime.

I’m using org.eclipse.osgi_3.10.101.v20150820-1432.jar

Thanks,

—
Derek


On 18 May 2016, at 18:58, Derek Baum <[email protected]> wrote:

I’m running with a SecurityManager installed and a trivial security.policy 
that grants AllPermission.

This works fine when running using the Felix runtime; however when I 
switch to Equinox I get security exceptions.

I’m not yet sure whether the problem lies with Felix config admin (1.8.8), 
Equinox runtime or elsewhere.


I’ve diagnosed the cause of the failure as follows:

Felix config admin ManagedServiceTracker, uses doPrivileged() to invoke 
the service.updated() method, with a new AccessControlContext:

      AccessController.doPrivileged(new PrivilegedExceptionAction() {
               public Object run() throws ConfigurationException {
                   service.updated( properties );
                   return null;
               }
            }, getAccessControlContext( service ) );

    AccessControlContext getAccessControlContext( final Object ref ) {
        return new AccessControlContext( new ProtectionDomain[]
            { ref.getClass().getProtectionDomain() } );
    }


Felix and Equinox return different ProtectionDomain implementations:

org.apache.felix.framework.BundleProtectionDomain
org.eclipse.osgi.internal.loader.ModuleClassLoader$GenerationProtectionDomain



Both implementations extend ProtectionDomain, but the Felix implementation 
uses the 4-arg constructor:

     The permissions granted to this domain are dynamic; they include
    both the static permissions passed to this constructor, and any
    permissions granted to this domain by the current Policy at the
     time a permission is checked.

while the Equinox implementation uses the 2-arg constructor.

    The only permissions granted to this domain
    are the ones specified; the current Policy will not be consulted


So the problem arises because Felix config admin is using doPrivileged() 
with a new AccessControlContext(), constructed using the target classes 
ProtectionDomain, and the ProtectionDomain returned when running on 
Equinox, does not consult the current policy, so my security policy 
containing grant AllPermission is ignored.


I’ve taken a quick look at the Equinox config admin implementation, and it 
doesn’t use doPrivileged() or a new AccessControlContext(),
so the issue does not arise.


Any opinions on whether this issue lies in Felix config admin, Equinox 
framework, or elsewhere?


Thanks,

—
Derek









_______________________________________________
equinox-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to