If I run :whoami operation with SM enabled, I get IllegalArgumentException and operation fails: --------------------------------------------------- [standalone@localhost:9999 /] :whoami { "outcome" => "failed", "result" => {"identity" => {"username" => undefined}}, "failure-description" => "JBAS014749: Operation handler failed: newValue is null", "rolled-back" => true } -------------------------------------------------- 12:03:28,440 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("whoami") failed - address: ([]): java.lang.IllegalArgumentException: newValue is null at org.jboss.dmr.ModelNode.set(ModelNode.java:499) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1] at org.jboss.as.domain.management.security.WhoAmIOperation.execute(WhoAmIOperation.java:96) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
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.