[JBoss JIRA] (WFLY-2584) RBAC: Silent failure of run-as role mapping
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2584?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2584:
----------------------------------------
I see no reason not to fail, the client only has the ability to request a reduced set of roles - if one of the roles they are requesting does not exist they should be informed.
Not reporting an error would only lead to confusion I think overall.
> RBAC: Silent failure of run-as role mapping
> -------------------------------------------
>
> Key: WFLY-2584
> URL: https://issues.jboss.org/browse/WFLY-2584
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> RunAsRoleMapper.mapRoles(Caller caller, Set<String> currentRoles, Set<String> runAsRoles, boolean sanitized) ignores false results from realRoleMapper.canRunAs(currentRoles, requestedRole) and just leaves the user running in their regular roles. Some sort of failure condition seems more appropriate.
> I noticed this when I was investigating WFLY-2318 caused by WFLY-2583. The improperly parsed role list was resulting in realRoleMapper.canRunAs(currentRoles, requestedRole) returning false so the call would just execute as SuperUser.
> Same thing would happen with a simple typo like {roles=Mnitor}.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1994) JPA module throws NPE when binding unavailable persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1994?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-1994:
-------------------------------
Fix Version/s: 8.0.0.CR1
> JPA module throws NPE when binding unavailable persistence unit
> ---------------------------------------------------------------
>
> Key: WFLY-1994
> URL: https://issues.jboss.org/browse/WFLY-1994
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha4
> Environment: Fedora 19, Wildfly a0c7edb142b75d92276fb9fa9c0033ea1d583934 or AS7.2.0
> Reporter: Brent Douglas
> Assignee: Scott Marlow
> Fix For: 8.0.0.CR1
>
>
> When binding an unavailable PU to JNDI an NPE is thrown rather than a message explaining the problem.
> {noformat}
> 13:33:55,185 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."fails.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fails.ear".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "fails.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitBindingSource(PersistenceRefProcessor.java:211)
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitRefs(PersistenceRefProcessor.java:127)
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.processDescriptorEntries(PersistenceRefProcessor.java:78)
> at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> ... 5 more
> {noformat}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1994) JPA module throws NPE when binding unavailable persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1994?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-1994.
------------------------------
> JPA module throws NPE when binding unavailable persistence unit
> ---------------------------------------------------------------
>
> Key: WFLY-1994
> URL: https://issues.jboss.org/browse/WFLY-1994
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha4
> Environment: Fedora 19, Wildfly a0c7edb142b75d92276fb9fa9c0033ea1d583934 or AS7.2.0
> Reporter: Brent Douglas
> Assignee: Scott Marlow
> Fix For: 8.0.0.CR1
>
>
> When binding an unavailable PU to JNDI an NPE is thrown rather than a message explaining the problem.
> {noformat}
> 13:33:55,185 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."fails.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fails.ear".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "fails.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitBindingSource(PersistenceRefProcessor.java:211)
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitRefs(PersistenceRefProcessor.java:127)
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.processDescriptorEntries(PersistenceRefProcessor.java:78)
> at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> ... 5 more
> {noformat}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1994) JPA module throws NPE when binding unavailable persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-1994?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-1994:
------------------------------------
Thanks for the fix Andrei Tretyakov!
> JPA module throws NPE when binding unavailable persistence unit
> ---------------------------------------------------------------
>
> Key: WFLY-1994
> URL: https://issues.jboss.org/browse/WFLY-1994
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha4
> Environment: Fedora 19, Wildfly a0c7edb142b75d92276fb9fa9c0033ea1d583934 or AS7.2.0
> Reporter: Brent Douglas
> Assignee: Scott Marlow
>
> When binding an unavailable PU to JNDI an NPE is thrown rather than a message explaining the problem.
> {noformat}
> 13:33:55,185 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."fails.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fails.ear".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "fails.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitBindingSource(PersistenceRefProcessor.java:211)
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitRefs(PersistenceRefProcessor.java:127)
> at org.jboss.as.jpa.processor.PersistenceRefProcessor.processDescriptorEntries(PersistenceRefProcessor.java:78)
> at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> ... 5 more
> {noformat}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Frank Cornelis (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Frank Cornelis commented on WFLY-1477:
--------------------------------------
What do you mean by "using web with WildFly"? I use the default Undertow. From a servlet I end up in some EJB3 session bean. There I do:
HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
and then it explodes. This should not happen. I should be able to get the HttpServletRequest.
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Remy Maucherat commented on WFLY-1477:
--------------------------------------
You mean you're still using web with Wildfly ? That would not be supported anymore.
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2583) Support multiple run-as roles from CLI and HTTP clients
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2583?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2583:
-----------------------------------
Description:
The "run-as" roles feature with RBAC will only allow multiple role declarations if the caller provides a ModelNode of type LIST. The CLI doesn't do that and clients using the HTTP interface (e.g. web console) cannot do that. This makes doing this largely unsupported except for things like unit tests that create custom clients.
Fix is to do some more sophisticated parsing in RunAsRolesMapper.getOperationHeaderRoles(...).
1) If the trimmed role-list string starts with [ and ends with ] try to use ModelNode.fromString to parse. Return result if no error.
2) If not, or there is a parse error in 1), check for "," and use String.split(",")
3) Just return the trimmed string in a ModelNode.
Step 2 makes "," a kind of privileged char in role names. However, in the extremely remote chance users want to include "," in role names and still use this feature, the solution is to use proper DMR syntax for the roles header value, e.g.
["yuck,commas","Maintainer"]
So, in the CLI:
$ :read-resource{roles=["yuck,commas","Maintainer"]}
An HTTP client like the console should use proper DMR syntax for the value of the operation-header-roles query parameter.
was:
The "run-as" roles feature with RBAC will only allow multiple role declarations if the caller provides a ModelNode of type LIST. The CLI doesn't do that and clients using the HTTP interface (e.g. web console) cannot do that. This makes doing this largely unsupported except for things like unit tests the create custom clients.
Fix is to do some more sophisticated parsing in RunAsRolesMapper.getOperationHeaderRoles(...).
1) If the trimmed role-list string starts with [ and ends with ] try to use ModelNode.fromString to parse. Return result if no error.
2) If not, or there is a parse error in 1), check for "," and use String.split(",")
3) Just return the trimmed string in a ModelNode.
Step 2 makes "," a kind of privileged char in role names. However, in the extremely remote chance users want to include "," in role names and still use this feature, the solution is to use proper DMR syntax for the roles header value, e.g.
["yuck,commas","Maintainer"]
So, in the CLI:
$ :read-resource{roles=["yuck,commas","Maintainer"]}
An HTTP client like the console should use proper DMR syntax for the value of the operation-header-roles query parameter.
> Support multiple run-as roles from CLI and HTTP clients
> -------------------------------------------------------
>
> Key: WFLY-2583
> URL: https://issues.jboss.org/browse/WFLY-2583
> Project: WildFly
> Issue Type: Requirement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.CR1
>
>
> The "run-as" roles feature with RBAC will only allow multiple role declarations if the caller provides a ModelNode of type LIST. The CLI doesn't do that and clients using the HTTP interface (e.g. web console) cannot do that. This makes doing this largely unsupported except for things like unit tests that create custom clients.
> Fix is to do some more sophisticated parsing in RunAsRolesMapper.getOperationHeaderRoles(...).
> 1) If the trimmed role-list string starts with [ and ends with ] try to use ModelNode.fromString to parse. Return result if no error.
> 2) If not, or there is a parse error in 1), check for "," and use String.split(",")
> 3) Just return the trimmed string in a ModelNode.
> Step 2 makes "," a kind of privileged char in role names. However, in the extremely remote chance users want to include "," in role names and still use this feature, the solution is to use proper DMR syntax for the roles header value, e.g.
> ["yuck,commas","Maintainer"]
> So, in the CLI:
> $ :read-resource{roles=["yuck,commas","Maintainer"]}
> An HTTP client like the console should use proper DMR syntax for the value of the operation-header-roles query parameter.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2488) Adding a datasource fails in a composite operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2488?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2488:
----------------------------------------
While it's a bug that this fails, it's a strange composite, since the 2nd step is just reiterating what the first already said.
> Adding a datasource fails in a composite operation
> --------------------------------------------------
>
> Key: WFLY-2488
> URL: https://issues.jboss.org/browse/WFLY-2488
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: James Perkins
> Assignee: Stefano Maestri
> Attachments: wfly2488-sources.jar, wfly2488.jar
>
>
> Executing a composite operation fails when adding a datasource.
> Stack Trace:
> {code}
> 08:38:49,787 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "ds-test")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.ds-test is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1422) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> 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.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1.jar:8.0.0.Beta1]
> 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.jar:2.1.1.Final]
> {code}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2584) RBAC: Silent failure of run-as role mapping
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2584?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2584:
-----------------------------------
Description:
RunAsRoleMapper.mapRoles(Caller caller, Set<String> currentRoles, Set<String> runAsRoles, boolean sanitized) ignores false results from realRoleMapper.canRunAs(currentRoles, requestedRole) and just leaves the user running in their regular roles. Some sort of failure condition seems more appropriate.
I noticed this when I was investigating WFLY-2318 caused by WFLY-2583. The improperly parsed role list was resulting in realRoleMapper.canRunAs(currentRoles, requestedRole) returning false so the call would just execute as SuperUser.
Same thing would happen with a simple typo like {roles=Mnitor}.
was:
RunAsRoleMapper.mapRoles(Caller caller, Set<String> currentRoles, Set<String> runAsRoles, boolean sanitized) ignores false results from realRoleMapper.canRunAs(currentRoles, requestedRole) and just leaves the user running in their regular roles. Some sort of failure condition seems more appropriate.
I noticed this when I was investigating WFLY-2318 caused by WFLY-2583. The improperly parsed role list was resulting in realRoleMapper.canRunAs(currentRoles, requestedRole) so the call would just execute as SuperUser.
Same thing would happen with a simple typo like {roles=Mnitor}.
> RBAC: Silent failure of run-as role mapping
> -------------------------------------------
>
> Key: WFLY-2584
> URL: https://issues.jboss.org/browse/WFLY-2584
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> RunAsRoleMapper.mapRoles(Caller caller, Set<String> currentRoles, Set<String> runAsRoles, boolean sanitized) ignores false results from realRoleMapper.canRunAs(currentRoles, requestedRole) and just leaves the user running in their regular roles. Some sort of failure condition seems more appropriate.
> I noticed this when I was investigating WFLY-2318 caused by WFLY-2583. The improperly parsed role list was resulting in realRoleMapper.canRunAs(currentRoles, requestedRole) returning false so the call would just execute as SuperUser.
> Same thing would happen with a simple typo like {roles=Mnitor}.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2584) RBAC: Silent failure of run-as role mapping
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2584:
--------------------------------------
Summary: RBAC: Silent failure of run-as role mapping
Key: WFLY-2584
URL: https://issues.jboss.org/browse/WFLY-2584
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Beta1
Reporter: Brian Stansberry
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
RunAsRoleMapper.mapRoles(Caller caller, Set<String> currentRoles, Set<String> runAsRoles, boolean sanitized) ignores false results from realRoleMapper.canRunAs(currentRoles, requestedRole) and just leaves the user running in their regular roles. Some sort of failure condition seems more appropriate.
I noticed this when I was investigating WFLY-2318 caused by WFLY-2583. The improperly parsed role list was resulting in realRoleMapper.canRunAs(currentRoles, requestedRole) so the call would just execute as SuperUser.
Same thing would happen with a simple typo like {roles=Mnitor}.
--
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
12 years, 8 months