[jboss-dev-forums] [Design of POJO Server] - Re: Naming lookup needs a getClassloader permission

[anil.saldhana@jboss.com]

Suddenly I have turned into a Santa Claus who brings JIRA issues. It is still November.

>From the stack trace:


  | 2008-11-18 13:52:53,897 ERROR [STDERR] (WorkerThread#3[127.0.0.1:40887]) access: domain that failed ProtectionDomain  (null <no signer certificates>)
  |  org.jboss.proxy.compiler.Runtime at 56683a8d
  |  <no principals>
  |  java.security.Permissions at 8465aab (
  |  (javax.management.MBeanServerPermission findMBeanServer)
  |  (javax.management.MBeanPermission org.jboss.mx.modelmbean.XMBean#*[JMImplementation:type=MBeanRegistry] *)
  |  (javax.management.MBeanPermission org.jboss.security.plugins.JaasSecurityManagerService#*[jboss.security:service=JaasSecurityManager] invoke)
  | ....
  | 
  | java.lang.IllegalStateException: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
  |         at org.jboss.security.plugins.JBossSecurityContext.getUtil(JBossSecurityContext.java:201)
  |         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.invokeGetRelatedId(JDBCCMRFieldBridge.java:1156)
  |         at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.createRelationLinks(JDBCCMRFieldBridge.java:988)
  | 
  | ....
  | Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
  |         at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
  |         at java.security.AccessController.checkPermission(AccessController.java:427)
  |         at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  |         at java.lang.ClassLoader.getParent(ClassLoader.java:1224)
  |         at org.jboss.classloading.spi.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:84)
  |         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  |         at org.jboss.util.loading.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:97)
  |         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
  |         at org.jboss.security.SecurityContextFactory.getContextClass(SecurityContextFactory.java:142)
  |         at org.jboss.security.SecurityContextFactory.createUtil(SecurityContextFactory.java:118)
  |         at org.jboss.security.plugins.JBossSecurityContext.getUtil(JBossSecurityContext.java:197)
  |         ... 82 more
  | 
  | 

Currently I feel that the offending class is the (surrogate) DelegatingClassLoader that sits in the "integration" project at:
http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-classloading-spi/src/main/java/org/jboss/classloading/spi/DelegatingClassLoader.java

Here calls to getParent() and super.loadClass  need to be shielded with priv blocks?  

This is because  for the users of CL, getting the classloader is a privileged operation, but loading the class is not.

Also I am wondering why the protection domain is null.  Is it because we are in the bootstrap zone when the perm check is done?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190254#4190254

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190254