[
https://issues.apache.org/jira/browse/FELIX-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15588109#comment-15588109
]
Paolo Antinori commented on FELIX-5148:
---------------------------------------
Hi guys, I'm trying to understand and possibly fix that KARAF-3400 issue.
I have spent some time in debug, and I can see what's the object state that
cause the failure but I have not been able yet to understand what leads to that
state.
First thing to notice is that {{adapt()}} call is just one of the places where
it fails. If you alter {{pax-logging}} code to bypass that call, other calls
will fail with an equivalent problem.
What I can see is that in {{AccessControlContext}} at the line linked here
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/security/AccessControlContext.java?av=f#435
{code:java}
if (context[i] != null && !context[i].implies(perm)) {
{code}
One of the {{context}}s fails that test.
That context is actually totally emtpy:
{code}
ProtectionDomain null
null
<no principals>
null
{code}
And since all the contexts need to allow the permission, the operation fails.
Enabling logging, I have a confirmation that the problem is that entirely empty
{{ProtectionDomain}}:
{code}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1329)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:447)
at
java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.File.exists(File.java:814)
at
org.ops4j.pax.url.mvn.internal.config.MavenConfigurationImpl.getSettingsFileUrl(MavenConfigurationImpl.java:166)
at
org.ops4j.pax.url.mvn.internal.config.MavenConfigurationImpl.getSettingsPath(MavenConfigurationImpl.java:584)
at
org.ops4j.pax.url.mvn.internal.config.MavenConfigurationImpl.<init>(MavenConfigurationImpl.java:102)
at org.ops4j.pax.url.mvn.internal.Activator.updated(Activator.java:175)
at
org.ops4j.pax.url.mvn.internal.Activator$OptionalConfigAdminHelper$1.updated(Activator.java:259)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker$1.run(ManagedServiceTracker.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:173)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1440)
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1396)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
at java.lang.Thread.run(Thread.java:745)
access: domain that failed ProtectionDomain null
null
<no principals>
java.security.Permissions@7c0c20b8 (
)
...
access: AccessControlContext invoking the Combiner
access: access denied ("java.lang.RuntimePermission" "getClassLoader")
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1329)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:447)
at
java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
at java.lang.Thread.getContextClassLoader(Thread.java:1436)
at
org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.updated(PaxLoggingServiceImpl.java:203)
at
org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.updated(PaxLoggingServiceImpl.java:362)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker$1.run(ManagedServiceTracker.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:173)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)
at
org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1440)
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1396)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
at java.lang.Thread.run(Thread.java:745)
access: domain that failed ProtectionDomain null
null
<no principals>
java.security.Permissions@7244eef5 (
)
{code}
I will try to investigate further but I'd appreciate some hint if anyone has
any.
FWIW I'm testing this with
{code:10}:56 $ java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
{code}
> Framework Security unusable
> ---------------------------
>
> Key: FELIX-5148
> URL: https://issues.apache.org/jira/browse/FELIX-5148
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin, Framework Security
> Affects Versions: framework.security-2.4.0, configadmin-1.8.0
> Reporter: Oliver Lietz
> Assignee: Karl Pauls
> Attachments: FELIX-5148.site.patch,
> FELIX-5148.sling-launchpad-builder.patch
>
>
> While fixing an issue with Sling and RMI (SLING-5375) reported by an user I
> came across an issue (KARAF-3400) reported by [~achim_nierbeck] for Karaf
> related to framework security.
> There is also an issue with [Sling's own OSGi launcher
> Launchpad|https://svn.apache.org/viewvc/sling/trunk/launchpad/builder/] and
> framework security when using {{org.apache.felix.configadmin}} >= {{1.8.0}}.
> {{all.policy}}:
> {noformat}
> grant {
> permission java.security.AllPermission;
> };
> {noformat}
> Adding {{org.apache.felix/org.apache.felix.framework.security/2.4.0}} to
> {{boot.txt}} and starting with arguments described on [Framework Security's
> page|http://felix.apache.org/documentation/subprojects/apache-felix-framework-security.html]
> (which looks broken) and
> [{{-Djava.security.manager}}|http://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc6.html]
> ([Building Secure OSGi
> Applications|http://de.slideshare.net/marrs/building-secure-osgi-applications])
> throws a {{java.security.AccessControlException}}:
> {noformat}
> java -Djava.security.manager -Djava.security.policy="all.policy"
> -Dorg.osgi.framework.security="osgi" -jar
> org.apache.sling.launchpad-9-SNAPSHOT.jar
> {noformat}
> {noformat}
> [...]
> [...] *ERROR* [FelixStartLevel] ERROR: Error starting
> slinginstall:org.apache.felix.configadmin-1.8.0.jar
> (java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/[...]/sling/config" "read"))
> java.security.AccessControlException: access denied ("java.io.FilePermission"
> "/[...]/sling/config" "read")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at
> org.apache.felix.cm.file.FilePersistenceManager.<init>(FilePersistenceManager.java:342)
> at
> org.apache.felix.cm.impl.ConfigurationManager.start(ConfigurationManager.java:244)
> at
> org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1709)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:688)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2144)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.lang.Thread.run(Thread.java:745)
> [...]
> {noformat}
> I had to remove OSGi Subsystems support from {{boot.txt}} when using
> {{org.apache.felix.configadmin}} {{1.6}}:
> {noformat}
> org.apache.felix/org.apache.felix.coordinator/1.0.0
> org.eclipse.equinox/org.eclipse.equinox.region/1.2.101.v20150831-1342
> org.apache.aries.subsystem/org.apache.aries.subsystem.api/2.0.6
> org.apache.aries.subsystem/org.apache.aries.subsystem.core/2.0.6
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
