felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4362) Security ConfigAdmin permissions are inherited on the stack
Date Sat, 28 Dec 2013 20:15:50 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858105#comment-13858105

Felix Meschberger commented on FELIX-4362:

Implemented calling the ManagedService[Factory] methods as privileged actions if a SecurityManager
is installed in Rev. 1553904.

As for the AccessControlContext required: I am not really sure, what AccessControlContext
we should use here, so an AccessControlContext is created using the called service's ProtectionDomain.
For sure, the AccessControlContext from AccessControll.getContext() cannot be used because
that is based on the ConfigurationAdmin bundle's protection domain.

The trunk build currently passes our own tests as well as OSGi CT tests.

Please check, whether a trunk build of the Configuration Admin bundle fixes your issues.

> Security ConfigAdmin permissions are inherited on the stack
> -----------------------------------------------------------
>                 Key: FELIX-4362
>                 URL: https://issues.apache.org/jira/browse/FELIX-4362
>             Project: Felix
>          Issue Type: Bug
>          Components: Configuration Admin
>    Affects Versions: configadmin-1.8.0
>            Reporter: Guillaume Nodet
>            Assignee: Felix Meschberger
>            Priority: Blocker
>             Fix For: configadmin-1.8.2
> It seems to cause lots of issues for me when testing.
> For example, I end up with lots of exceptions like:
> [CM Configuration Updater (ManagedServiceFactory Update: factoryPid=[org.apache.felix.fileinstall])]
ERROR org.apache.felix.configadmin - [org.osgi.service.cm.ManagedServiceFactory, id=233, bundle=7/mvn:org.apache.felix/org.apache.felix.fileinstall/3.2.6]:
Unexpected problem updating configuration org.apache.felix.fileinstall.c0eba252-35f7-4ab6-bc11-ad11e131711c
> java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.io.tmpdir"
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
> 	at java.security.AccessController.checkPermission(AccessController.java:559)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
> 	at java.lang.System.getProperty(System.java:708)
> 	at org.apache.felix.fileinstall.internal.DirectoryWatcher.<init>(DirectoryWatcher.java:109)
> 	at org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:246)
> 	at org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:422)
> 	at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:88)
> 	at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1605)
> 	at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1548)
> 	at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> 	at java.lang.Thread.run(Thread.java:744)
> I think if we want to allow such a permissions file, we also need to ensure that all
access to bundles are not conditioned by it.
> In the above stack trace and when running with a security manager, the call to service.updated()
should be done inside a priviledged action I think:
> {code}
>   return AccessController.doPrivileged(new PrivilegedAction<Object>() {
>     public Object run() { service.updated( configPid.toString(), props ); }
>   }, accessControlContext);
> {code}
> so that permissions of ConfigAdmin bundle are not inherited by other bundles.

This message was sent by Atlassian JIRA

View raw message