[JBoss JIRA] (WFLY-2317) Trying to remove a server group as a server-group-scoped role leaks information
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784] from MODIFIED to ON_QA
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
> Key: WFLY-2317
> URL: https://issues.jboss.org/browse/WFLY-2317
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
> /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
> /core-service=management/access=authorization/role-mapping=NewRole:add
> /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
> /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
> exit
> [1] ^C
> ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
> /server-group=other-server-group:read-resource
> /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
> "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
> "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.
--
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-2270) Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738] from MODIFIED to ON_QA
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-2270
> URL: https://issues.jboss.org/browse/WFLY-2270
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
> <host-scoped-roles>
> <role name="master-Monitior" base-role="MONITOR">
> <host name="master"/>
> </role>
> </host-scoped-roles>
> {code}
> {code}
> <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain@localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
> "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller] ("core-service" => "management"),
> [Host Controller] ("access" => "authorization"),
> [Host Controller] ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.
--
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-1740) ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1740:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1017747|https://bugzilla.redhat.com/show_bug.cgi?id=1017747] from MODIFIED to ON_QA
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-1740
> URL: https://issues.jboss.org/browse/WFLY-1740
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Alpha4
> Reporter: Cheng Fang
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> High Confidence Correctness
>
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)
--
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-1499) Clustering tests intermittently fail mainly because they do not clean their deployments properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1499:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371] from MODIFIED to ON_QA
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-1499
> URL: https://issues.jboss.org/browse/WFLY-1499
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ivo Studensky
> Assignee: Radoslav Husar
> Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms. Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.
--
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-2278) Deployer can't modify data source when datasources set as application resources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from MODIFIED to ON_QA
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
> Key: WFLY-2278
> URL: https://issues.jboss.org/browse/WFLY-2278
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.
--
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