[jira] [Commented] (FELIX-5976) Deadlock can occur when loading class in Permissions.java

["Karl Pauls (JIRA)" <ji...@apache.org>]

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

Karl Pauls commented on FELIX-5976:
-----------------------------------

Hm, can you maybe avoid the lookup of the Permission by changing the permission set-up you have? Maybe if you would give the bundle that triggers the permission check allpermission?

> 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
>            Priority: Blocker
>
> 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)