Timothy Carroll created FELIX-5976:
--------------------------------------
Summary: Deadlock can occur when loading class in Permissions.java
Key: FELIX-5976
URL: https://issues.apache.org/jira/browse/FELIX-5976
Project: Felix
Issue Type: Bug
Environment: Centos, Apache Catalina
Reporter: Timothy Carroll
My company is attempting to use Felix Framework Security, but we are running
into a race condition that can lead to thread deadlock. The Felix Security
class causing the deadlock is
{{org.apache.felix.framework.security.util.Permissions.java}}
We're using Felix Security v2.4.0 in a Tomcat Catalina app server v8.5.34. We
believe the issue could occur in the latest Felix Security version as well. The
line of code in questions is line 530 where the
{{Permissions.createPermission}} method attempts to load a class.
We found that the deadlock occurs if the {{loadClass}} method ends up using the
root Catalina class loader, {{WebappClassLoaderBase}}. Essentially, we have a
case where we use {{javax.xml}} to serialize or deserialize something in an
OSGI bundle which results in a call to
{{org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntries}},
which is a largely synchronized method. While attempting to get the entries,
we run into a permissions check that needs to obtain the lock managed by
{{WebappClassLoaderBase}} because of line 530.
At the same time, we run into a reversed lock order from some older,
pre-existing code that is not directly controlled by us. Essentially, our
servlet filters attempt to load a class, obtaining the lock on
{{WebappClassLoaderBase}}. The class loader (not in our code) is doing
something, however, that needs to load archive entries through OSGI which runs
into the lock on
{{org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntries}}.
Thus, we have a deadlock.
Since the pre-existing code that obtains the locks in the order
{{WebappClassLoaderBase}} > {{AbstractSingleArchiveResourceSet}} is much more
opaque and also preexisting in our codebase, we're hoping that we can figure
out how to avoid the check on line 530 of {{Permissions}}. It seems like it
could be unnecessary, but we would love some assistance from Karl or anyone
else familiar with the security framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
