Hi Tom,
The reason that the Equinox Protection Domain is not granting all permissions,
is because it uses the 2-arg ProtectionDomain constructor, which does not
consult the security policy:
public GenerationProtectionDomain(CodeSource codesource, PermissionCollection
permissions, Generation generation) {
super(codesource, permissions);
this.generation = generation;
}
public ProtectionDomain(CodeSource
<http://docs.oracle.com/javase/8/docs/api/java/security/CodeSource.html>
codesource,
PermissionCollection
<http://docs.oracle.com/javase/8/docs/api/java/security/PermissionCollection.html>
permissions)
Creates a new ProtectionDomain with the given CodeSource and Permissions. If
the permissions object is not null, thensetReadOnly()) will be called on the
passed in Permissions object. The only permissions granted to this domain are
the ones specified; the current Policy will not be consulted
Using the 4-arg constructor (with extra args null) would resolve the problem,
as it does check the security policy:
public ProtectionDomain(CodeSource
<http://docs.oracle.com/javase/8/docs/api/java/security/CodeSource.html>
codesource,
PermissionCollection
<http://docs.oracle.com/javase/8/docs/api/java/security/PermissionCollection.html>
permissions,
ClassLoader
<http://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html>
classloader,
Principal
<http://docs.oracle.com/javase/8/docs/api/java/security/Principal.html>[]
principals)
Creates a new ProtectionDomain qualified by the given CodeSource, Permissions,
ClassLoader and array of Principals. If the permissions object is not null,
then setReadOnly() will be called on the passed in Permissions object. 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
Do you still want me to open a bug on this?
—
Derek
> On 20 May 2016, at 13:51, Thomas Watson <[email protected]> wrote:
>
> 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(newSecurityManager());
> }
>
> with the java.security.policySystem 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]
> <mailto:[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] <mailto:[email protected]>>
> To: [email protected] <mailto:[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]
> <mailto:[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]
> <mailto:[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] <mailto:[email protected]>
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> <https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list
> [email protected] <mailto:[email protected]>
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> <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
> <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
