Description Simon Kaegi 2010-11-01 13:59:46 EDT

Cloned to back-port the fix to 3.6 maintenance branch.

+++ This bug was initially created as a clone of Bug #327482 +++

AccessControlException seen when an OSGI application is run in WebSphere when Java 2 security is enabled.

Steps to Recreate:
Install an OSGI web application in WebSphere and enable Java 2 security.
When I attempt to load the application, I get exceptions in the log:

Permission:
      setContextClassLoader : Access denied (java.lang.RuntimePermission setContextClassLoader)

Code:
     org.apache.jsp.index_jsp  in  {file:/G:/wasX/profiles/Dmgr02/temp/HumeCellManager41/dmgr/isclite/iehs.war/proxytemp/hc_30600740/}

Stack Trace:
java.security.AccessControlException: Access denied (java.lang.RuntimePermission setContextClassLoader)
	at java.security.AccessController.checkPermission(AccessController.java:108)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
	at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
	at java.lang.Thread.setContextClassLoader(Thread.java:754)
	at com.ibm.ws.util.ThreadPool$Worker.setContextClassLoader(ThreadPool.java:1773)
	at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1138)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:708)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:435)

The problem is that the was.policy file which grants AllPermission to the ear does not get applied to the OSGI war binaries which have been extracted to the temp directory.
A known workaround is to edit the server.policy file to grant AllPermission for this temp path as the codeBase. This workaround should not be needed if the permissions are inherited correctly from the ear's .policy file.

We think the issue is the org.eclipse.equinox.servletbridge.BridgeServlet class uses the class loader org.eclipse.equinox.servletbridge.CloseableURLClassLoader to load the framework (the jars that got extracted to the temp directory).  The CloseableClassLoader extends URLClassLoader.  By default the URLClassLoader uses the built in policy.  I think WAS sets up a built-in security policy that only understands how to grant permissions to the server's codebase and to class loaders it controls.  It knows nothing about CloseableClassLoader.  I think CloseableClassLoader should override the method java.net.URLClassLoader.getPermissions(CodeSource) in order to grant all permissions to the framework jar (codebase) that it extracted.