[JBoss JIRA] (WFLY-2131) read-operation-names to return a filtered list of allowed operations
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-2131:
----------------------------------
After speaking to Brian we decided to leave the plain :read-operation-names as it is for backwards compatibility, in case others than just CLI also rely on this operation. So to get the new behaviour I'll do 1) e.g. :read-operation-names(access-control=true). If 1) is done, you also get 2). 2) will be some header containing the stripped out operations, I will look at read-resource for inspiration.
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
> Key: WFLY-2131
> URL: https://issues.jboss.org/browse/WFLY-2131
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Alexey Loubyansky
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.
--
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
10 years, 6 months
[JBoss JIRA] (WFLY-2180) Thread threads pools inherit security context of submitting threads
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2180?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2180:
--------------------------------------
Basically the way to fix this is to make sure that every thread pool we use uses a factory that sets the correct access control context for created threads. This can be easily done using a JBossThreadFactory.
> 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
> 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
10 years, 6 months