Bug 1034700 - [CCC] (6.3) whoami operation doesn't work with security manager enabled
Summary: [CCC] (6.3) whoami operation doesn't work with security manager enabled
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: DR0
: EAP 6.3.0
Assignee: Darran Lofthouse
QA Contact: Petr Kremensky
Russell Dickenson
Depends On:
Blocks: 918459 1035231 1036618 1040480
TreeView+ depends on / blocked
Reported: 2013-11-26 11:06 UTC by Josef Cacek
Modified: 2014-07-21 03:15 UTC (History)
14 users (show)

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.
Clone Of:
Last Closed: 2014-06-28 15:42:47 UTC
Type: Bug

Attachments (Terms of Use)
preliminary patch (1.33 KB, patch)
2013-11-27 08:16 UTC, Ladislav Thon
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat One Jira Issue Tracker WFLY-2585 Critical Resolved Correct the identification of the current caller when a security manager is enabled. 2017-06-07 04:37:54 UTC

Description Josef Cacek 2013-11-26 11:06:09 UTC
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]

Comment 1 Josef Cacek 2013-11-26 11:07:52 UTC
The operation worked in 6.1.1.

Comment 2 Ladislav Thon 2013-11-26 11:29:55 UTC
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.

Comment 3 Josef Cacek 2013-11-26 21:46:38 UTC
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:

There could be more places, where the AccessController.doPrivileged() method call could have unwanted effect.

Comment 4 Josef Cacek 2013-11-26 22:29:31 UTC
Another class, which has to be fixed is org.jboss.as.jmx.PluggableMBeanServerImpl.getCaller() from jmx module.

Comment 5 Ladislav Thon 2013-11-27 07:06:27 UTC
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.

Comment 6 Ladislav Thon 2013-11-27 07:08:06 UTC
CCing Darran, as I've been talking about this with him yesterday and he was investigating it too.

Comment 7 Ladislav Thon 2013-11-27 08:16:13 UTC
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.

Comment 8 Josef Cacek 2013-11-27 11:15:37 UTC
One more place to fix:

Comment 9 Darran Lofthouse 2013-11-27 12:08:25 UTC
Please disregard the patches on here - I am working on this upstream.

Comment 10 JBoss JIRA Server 2013-11-27 14:08:39 UTC
Darran Lofthouse <darran.lofthouse@jboss.com> 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.

Comment 11 JBoss JIRA Server 2013-11-27 18:13:42 UTC
Darran Lofthouse <darran.lofthouse@jboss.com> updated the status of jira WFLY-2585 to Coding In Progress

Comment 17 Ondrej Lukas 2014-02-26 08:37:56 UTC
Verified on EAP 6.3.0.DR0.

Comment 22 Josef Cacek 2014-07-08 15:38:25 UTC
I'm not able to clear "atsec" group checkbox, so I can't make the BZ public.

Note You need to log in before you can comment on or make changes to this bug.