Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 329204

Summary: OSGi app binaries do not inherit Java 2 security
Product: [Eclipse Project] Equinox Reporter: Simon Kaegi <simon_kaegi>
Component: Server-SideAssignee: equinox.server-side-inbox <equinox.server-side-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: gunnar, jcr2548, simon_kaegi, tjwatson
Version: 3.4.2Flags: tjwatson: review+
Target Milestone: 3.4.2+   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 327482, 329212    
Bug Blocks:    
Attachments:
Description Flags
Proposed Patch
none
proposed patch v2
none
proposed patch v3 none

Description Simon Kaegi CLA 2010-11-01 12:45:23 EDT
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.
Comment 1 Simon Kaegi CLA 2010-11-01 12:54:39 EDT
Created attachment 182156 [details]
Proposed Patch
Comment 2 Simon Kaegi CLA 2010-11-01 12:55:25 EDT
Tom, could you review please. Thanks.
Comment 3 Simon Kaegi CLA 2010-11-01 13:01:04 EDT
Created attachment 182157 [details]
proposed patch v2

Last patch forgot to bump version
Comment 4 Simon Kaegi CLA 2010-11-01 13:57:20 EDT
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.
Comment 5 Thomas Watson CLA 2010-11-01 16:42:47 EDT
Looks good.  Still need to revalidate the fix with the reporter of bug327482
Comment 6 Simon Kaegi CLA 2010-11-04 10:43:35 EDT
Thanks Tom. Re-validated and committed.
Comment 7 jcr2548 CLA 2010-11-09 10:42:12 EST
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.
Comment 8 Thomas Watson CLA 2010-11-09 11:25:28 EST
(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.