Bug 1119147

Summary: (6.4.0) Security Manager related issue in Http11NioProtocol
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Hynek Mlnarik <hmlnarik>
Component: WebAssignee: Rémy Maucherat <rmaucher>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Slavicek <pslavice>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.3.0CC: bbaranow, cdewolf, kkhan, mkopecky, pkremens, pslavice, rmaucher
Target Milestone: DR11   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1161125 (view as bug list) Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 996500, 1104190, 1111137, 1123901, 1157438, 1161125    
Attachments:
Description Flags
NioEndpoint.java 7.5.x branch patch none

Description Hynek Mlnarik 2014-07-14 06:56:35 UTC
Description of problem:
Using org.apache.coyote.http11.Http11NioProtocol as HTTP protocol handler in EAP 6.3.0.ER9 run with security manager on OpenJDK 7u55 leads to the following exception.

ERROR [org.apache.catalina.connector] (http-/127.0.0.1:8080-8) JBWEB001018: An exception or error occurred in the container during the request processing: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "setContextClassLoader")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372) [rt.jar:1.7.0_55]
	at java.security.AccessController.checkPermission(AccessController.java:559) [rt.jar:1.7.0_55]
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_55]
	at java.lang.Thread.setContextClassLoader(Thread.java:1503) [rt.jar:1.7.0_55]
	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:218)
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185)
	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121)
	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228)
	at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:231)
	at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818)
	at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:935)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]


How reproducible:
Everytime

Steps to Reproduce:
1. Set up HTTP connector like this:
   <connector name="http" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="http" socket-binding="http" />
2. Start EAP and access the http://localhost:8080/

Actual results:
Exception is thrown and logged.

Expected results:
No exception thrown.

Additional info:
The exception is neither thrown for OpenJDK 7u60 nor for Oracle JDK 7u51

Comment 1 Josef Cacek 2014-07-23 14:52:36 UTC
Updating status. The same problem is in IBM JDK 7 (and EAP 6.3.0.ER10). Moving under the Web component.

Comment 3 Martin Velas 2014-08-04 08:49:06 UTC
Issue is still valid for EAP 6.3.0.ER10 bits.

Comment 4 Petr Kremensky 2014-08-29 13:00:50 UTC
Seen in EAP 6.3.1.CP.CR1

Comment 5 Rémy Maucherat 2014-10-06 12:21:48 UTC
After starting with the other issues, I'm moving on with connector and websockets issues. This one could be an issue with the connector misbehaving after the initial request. Anyway if you want to look at it right now and you find something, I have nothing against that.

Comment 6 Dominik Pospisil 2014-10-09 08:05:59 UTC
I have been looking into NIO connector code but did not found anything suspicious. The root case of the failure is that the relevant AccessControlContext.optimize() results with a stack containing empty ProtectionDomain [null,null]. I have built latest OpendJDK8 from sources to debug the issue but with that the issue is not reproducible - connector works as expected. So maybe a bug in JDK which has been fixed upstream?

Comment 7 Dominik Pospisil 2014-10-14 12:08:55 UTC
Seems that we are hitting the same problem as here:
https://issues.apache.org/jira/browse/SSHD-332

The NioEndpoint.DefaultThreadFactory.newThread() is invoked in an sun.misc.InnocuousThread which has associated empty protection domain. The empty protection domain is than inherited in the Thread created by the DefaultThreadFactory and this is what is causing the security exception. Creating the thread in a privileged block solves the problem.

Comment 8 Rémy Maucherat 2014-10-14 14:06:54 UTC
Maybe. But the thing I don't like in this bug report is that it shouldn't be running this stack trace at all doing regular keepalive.

Comment 9 Dominik Pospisil 2014-10-14 16:59:44 UTC
Created attachment 946971 [details]
NioEndpoint.java 7.5.x branch patch

Comment 13 Dominik Pospisil 2014-11-12 14:26:20 UTC
Same patch applies to 7.4 branch as well (BZ1161125).

Comment 14 Rémy Maucherat 2014-11-12 15:20:08 UTC
So in the meantime I heard it couldn't be reproduced. If it is a real bug, then see my previous comment: this shouldn't be happening at all. So it is weird.

Comment 15 Rémy Maucherat 2014-11-13 15:43:10 UTC
I don't understand why this didn't stay as NEW rather than POST since no fix has been integrated.

The analysis:
- This would be limited to one JDK despite any reasonable logic
- I verified that for a request to http://localhost:8080/ it doesn't enter event mode as demonstrated in the stack trace from the description (which would be a huge bug)

So I am setting the nack flag since I don't see any problem at the moment.

Comment 16 Dominik Pospisil 2014-11-18 20:52:21 UTC
I can still reproduce it using latest 6.x build (19db471fec5a50b138544a9c69a847b605a92ac8) on JDK 1.7.0_71 OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) and Oracle JDK 1.8.0_20-b26.

Comment 19 Rémy Maucherat 2014-11-18 22:12:10 UTC
Ok, let's not waste time in pointless discussions, I get the idea. Patch committed as r2546.

Comment 23 Hynek Mlnarik 2014-11-28 14:44:26 UTC
Verified in 6.4.0.DR11