Community
Participate
Working Groups
Tracking the backport of this fix into the 3.4 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.
Created attachment 182156 [details] Proposed Patch
Tom, could you review please. Thanks.
Created attachment 182157 [details] proposed patch v2 Last patch forgot to bump version
Created attachment 182164 [details] proposed patch v3 Tom pointed out an unnecessary code path for which the changes are now removed although we now need to re-validate.
Looks good. Still need to revalidate the fix with the reporter of bug327482
Thanks Tom. Re-validated and committed.
Is there a target date for when the 3.4.x patch/fix will be available for us to bundle in our product? Also, where would I download it? Thanks.
(In reply to comment #7) > Is there a target date for when the 3.4.x patch/fix will be available for us to > bundle in our product? > Also, where would I download it? > > Thanks. Equinox has no more planned releases in the 3.4.x stream. The fix has been released to the maintenance stream but Eclipse will not have a build of 3.4.x that you can download. This is something your product team (hint IES) would have to provide support for.
