[
https://issues.jboss.org/browse/WFLY-2180?page=com.atlassian.jira.plugin....
]
David Lloyd resolved WFLY-2180.
-------------------------------
Resolution: Done
Some time ago I went through and cleaned up all of the spots where we are creating thread
pools. For now if any new cases come up, we'll deal with them one at a time.
Thread threads pools inherit security context of submitting threads
-------------------------------------------------------------------
Key: WFLY-2180
URL:
https://issues.jboss.org/browse/WFLY-2180
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EE, EJB, Server, Web (Undertow)
Affects Versions: 8.0.0.Alpha4
Reporter: Stuart Douglas
Assignee: David Lloyd
Some thread pool implementation will immediately create a new thread if work is submitted
and there is not enough threads available to handle it. This newly created thread will
inherit the access control context of the thread that is submitting the work, which
essentially means that thread pool threads have a random access control context.
This is the root cause of UNDERTOW-102, and likely other security manager related
failures as well.
I think that the best way to fix this is in the thread pool itself, as it should create
the thread in a privileged block. We obviously cannot do this for JDK thread pools
however.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira