felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs
Date Thu, 29 Dec 2016 10:53:58 GMT

     [ https://issues.apache.org/jira/browse/FELIX-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Carsten Ziegeler closed FELIX-5275.
-----------------------------------

> Felix & Equinox handling of OSGI-INF/permissions.perm differs
> -------------------------------------------------------------
>
>                 Key: FELIX-5275
>                 URL: https://issues.apache.org/jira/browse/FELIX-5275
>             Project: Felix
>          Issue Type: Bug
>          Components: Configuration Admin, Framework Security
>    Affects Versions: configadmin-1.8.8
>         Environment: Felix config-admin 1.8.8 running on Equinox with SecurityManager
>            Reporter: Derek Baum
>
> Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, causes the
ManagedService.updated() method to get AccessControlExceptions when, for example, accessing
System properties.
> This is caused by:
> #1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039
> #2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox.
> I have previously raised this problem against Equinox (see External Issue URL), and this
is the gist of their analysis:
> ---------------------------
> The felix CM implementation is scoping their own permissions down to a strict subset
of permissions and Equinox is correctly enforcing that subset of permissions.
> So your bundle tries to read a system property, but the CM impl is not authorized to
read that property.
> One complication may be that Felix is allowing its bundle protection domains to be configured
with the java policy file (because their ProtectionDomains are constructed with that 4 arg
constructor).
> This would seem to break the specified behavior though, because clearly the CM implementation
should never be allowed to have permission to do things outside of what is specified by the
permissions.perm file or that are "implied" permissions auto-granted by the framework for
each bundle.
> -----------------------



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message