[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, 2 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, 2 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, 2 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, 2 months
[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1094:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 956391|https://bugzilla.redhat.com/show_bug.cgi?id=956391] from MODIFIED to ON_QA
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
> Key: WFLY-1094
> URL: https://issues.jboss.org/browse/WFLY-1094
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Hauke Mehrtens
> Assignee: Tomaz Cerar
> Labels: https, jsse, ssl
> Fix For: 8.0.0.Alpha1
>
> Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> {code:xml}
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
> <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> {code}
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
--
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, 2 months
[JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous disabling local authentication
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on REMJMX-74:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1021630|https://bugzilla.redhat.com/show_bug.cgi?id=1021630] from MODIFIED to ON_QA
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
> Key: REMJMX-74
> URL: https://issues.jboss.org/browse/REMJMX-74
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.2.Final, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.
--
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, 2 months