Bug 1034700
Summary: | [CCC] (6.3) whoami operation doesn't work with security manager enabled | ||||||
---|---|---|---|---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Josef Cacek <jcacek> | ||||
Component: | Domain Management | Assignee: | Darran Lofthouse <darran.lofthouse> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Kremensky <pkremens> | ||||
Severity: | high | Docs Contact: | Russell Dickenson <rdickens> | ||||
Priority: | unspecified | ||||||
Version: | 6.2.0 | CC: | brian.stansberry, cdewolf, darran.lofthouse, emuckenh, jawilson, jcacek, jkudrnac, jskeoch, kkhan, lcosti, lthon, myarboro, olukas, smumford | ||||
Target Milestone: | DR0 | Keywords: | Regression | ||||
Target Release: | EAP 6.3.0 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: |
The `:whoami` operation did not run correctly when JBoss EAP 6 was running with the Java Security Manager enabled. Attempting to run this operation in this situation would result in an `IllegalArgumentException` being thrown. This occurred because of invalid `AccessControlContext` situations where the identification of the current caller was incorrect.
This issue has been fixed in this release by accessing the current `AccessControlContext` outside of the privileged action. As a result, the `:whoami` operation will now run correctly when JBoss EAP 6 is running with the Java Security Manager enabled.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-06-28 15:42:47 UTC | 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: | 918459, 1035231, 1036618, 1040480 | ||||||
Attachments: |
|
Description
Josef Cacek
2013-11-26 11:06:09 UTC
The operation worked in 6.1.1. This is not only about :whoami. A lot of RBAC tests is failing under security manager -- my current speculation is that there's something wrong with subject propagation and all calls are treated as IN-VM calls. I've found the cause of the failing :whoami operation. The problem is in implementation of anonymous class assigned to org.jboss.as.controller.SecurityActions.CreateCallerActions.PRIVILEGED. There is a call of AccessController.doPrivileged(...) method, but this call cuts off associated Subject which comes from Subject.doAs(...) call - earlier on the call stack. More details about this behavior is described here: http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Frsec_jaasauthor.html There could be more places, where the AccessController.doPrivileged() method call could have unwanted effect. Another class, which has to be fixed is org.jboss.as.jmx.PluggableMBeanServerImpl.getCaller() from jmx module. I found the same thing, as can be seen at http://pastebin.test.redhat.com/178513 and http://pastebin.test.redhat.com/178514. Obtaining an AccessControlContext before calling doPrivileged and passing it as a second parameter of doPrivileged seems to fix the issue, but I don't know if this is the right thing we want to do. CCing Darran, as I've been talking about this with him yesterday and he was investigating it too. Created attachment 829608 [details]
preliminary patch
Here's a patch that fixes the RBAC standalone tests. HOWEVER:
1. I don't know if this is the right approach to fix the problem. It merely makes the tests pass.
2. There is a TON of other places where we're calling AccessController.doPrivileged. I can't imagine reviewing all of them.
One more place to fix: org.jboss.as.controller.remote.SecurityActions Please disregard the patches on here - I am working on this upstream. Darran Lofthouse <darran.lofthouse> made a comment on jira WFLY-2585 In addition to the access control related changes thoroughly check additional places where the current AccessControlContext is obtained within a PriviledgedAction. Some places may want a clean AccessControlContext that looses the information about the caller, others may genuinely want the current AccessControlContext but instead accidentally replace it. Darran Lofthouse <darran.lofthouse> updated the status of jira WFLY-2585 to Coding In Progress Verified on EAP 6.3.0.DR0. I'm not able to clear "atsec" group checkbox, so I can't make the BZ public. |