Bug 58125 - java.lang.ClassCircularityError can occur if Tomcat is run with a Java Security Manager
java.lang.ClassCircularityError can occur if Tomcat is run with a Java Securi...
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: Catalina
8.0.24
PC Linux
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
: 58199 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2015-07-11 18:43 UTC by Richard Evans
Modified: 2015-08-05 14:03 UTC (History)
1 user (show)



Attachments
Hand crafted test case which provokes similar error (3.19 KB, text/x-java)
2015-07-11 19:01 UTC, Richard Evans
Details
Java policy file for use with test (179 bytes, text/plain)
2015-07-11 19:02 UTC, Richard Evans
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Evans 2015-07-11 18:43:58 UTC
Tomcat 8.0.24, Java 1.8u45.

Run Tomcat is run with a Java security manager, and a ppolicy file containing a grant to a principal class, as in:

grant principal javax.management.remote.JMXPrincipal "jmx" {
    permission java.security.AllPermission;

};

On a thread with an implied Subject containing at least one Principal, perform an action which requires a Java permission check.  The Java Policy file implementation will attempt to load the principal class from the policy file.  The tomcat WebAppClassLoaderBase.loadClass method will check for a system class using getResource on the system loader.  This will in turn trigger another permission check which will then attempt to load the principal class again, triggering the ClassCircularityError.  

Here's a stack trace extract showing the error:

Class<T>.forName(String, boolean, ClassLoader) line: 348	
PolicyFile.addPermissions(Permissions, CodeSource, Principal[], PolicyFile$PolicyEntry) line: 1357	
PolicyFile.getPermissions(Permissions, CodeSource, Principal[]) line: 1228	
PolicyFile.getPermissions(Permissions, ProtectionDomain) line: 1191	
PolicyFile.getPermissions(ProtectionDomain) line: 1132	
PolicyFile.implies(ProtectionDomain, Permission) line: 1086	
ProtectionDomain.implies(Permission) line: 272	
AccessControlContext.checkPermission(Permission) line: 435	
AccessController.checkPermission(Permission) line: 884	
SecurityManager.checkPermission(Permission) line: 549	
URLClassPath.check(URL) line: 607	
URLClassPath$JarLoader.checkResource(String, boolean, JarEntry) line: 924	
URLClassPath$JarLoader.getResource(String, boolean) line: 1007	
URLClassPath.getResource(String, boolean) line: 212	
URLClassPath.getResource(String) line: 265	
ClassLoader.getBootstrapResource(String) line: 1261	
Launcher$ExtClassLoader(ClassLoader).getResource(String) line: 1090	
WebappClassLoader(WebappClassLoaderBase).loadClass(String, boolean) line: 1230	
WebappClassLoader(WebappClassLoaderBase).loadClass(String) line: 1164	
Class<T>.forName0(String, boolean, ClassLoader, Class<?>) line: not available [native method]	
Class<T>.forName(String, boolean, ClassLoader) line: 348	
PolicyFile.addPermissions(Permissions, CodeSource, Principal[], PolicyFile$PolicyEntry) line: 1357	
PolicyFile.getPermissions(Permissions, CodeSource, Principal[]) line: 1228	
PolicyFile.getPermissions(Permissions, ProtectionDomain) line: 1191	
PolicyFile.getPermissions(ProtectionDomain) line: 1132	
PolicyFile.implies(ProtectionDomain, Permission) line: 1086	
ProtectionDomain.implies(Permission) line: 272	
AccessControlContext.checkPermission(Permission) line: 435	
AccessController.checkPermission(Permission) line: 884	
SecurityManager.checkPermission(Permission) line: 549	
SecurityManager.checkRead(String) line: 888
Comment 1 Richard Evans 2015-07-11 19:01:55 UTC
Created attachment 32897 [details]
Hand crafted test case which provokes similar error
Comment 2 Richard Evans 2015-07-11 19:02:31 UTC
Created attachment 32898 [details]
Java policy file for use with test
Comment 3 Richard Evans 2015-07-11 19:03:12 UTC
Run test with:

$ java -Djava.security.manager -Djava.security.policy==all.policy  rde.tests.security.perm
Comment 4 Mark Thomas 2015-07-30 14:16:47 UTC
Thanks for the report. This has been fixed in trunk and 8.0.x for 8.0.25 onwards. 7.0.x does not use getResource() to avoid the CNFE so is not affected by this bug.
Comment 5 Mark Thomas 2015-08-05 14:03:40 UTC
*** Bug 58199 has been marked as a duplicate of this bug. ***