March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2585) Servers in domain don't start if management interfaces are bound to all IPv4 addresses

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2585?page=com.atlassian.jira.plugi... ] Brian Stansberry moved JBEAP-9924 to WFCORE-2585: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2585 (was: JBEAP-9924) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: 3.0.0.Beta11 (was: 7.1.0.DR15) Affects Testing: (was: Regression) > Servers in domain don't start if management interfaces are bound to all IPv4 addresses > -------------------------------------------------------------------------------------- > > Key: WFCORE-2585 > URL: https://issues.jboss.org/browse/WFCORE-2585 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta11 > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Priority: Blocker > Attachments: host-controller.log, server-one.log > > > This is regression compared to EAP 7.0.0. > See attached logs server-one.log , host-controller.log > {code} > ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 2) MSC000001: Failed to start service jboss.server-boot-operations: org.jboss.msc.service.StartException in service jboss.server-boot-operations: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:72) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote://0.0.0.0:9999. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:121) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.server.mgmt.domain.HostControllerConnection.openConnection(HostControllerConnection.java:128) > at org.jboss.as.server.mgmt.domain.HostControllerClient.resolveBootUpdates(HostControllerClient.java:110) > at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$1.run(ServerBootOperationsService.java:68) > ... 4 more > Caused by: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:426) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:241) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:427) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:415) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:177) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:113) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7564) EJB Attachment protocol mismatch

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-7564. ------------------------------- Resolution: Done > EJB Attachment protocol mismatch > -------------------------------- > > Key: WFLY-7564 > URL: https://issues.jboss.org/browse/WFLY-7564 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good. > The fix: > * In protocol 3 and higher, always read and write a packed integer > * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present > Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7564) EJB Attachment protocol mismatch

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7564?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-7564: ------------------------------ Fix Version/s: 11.0.0.Alpha1 (was: 11.0.0.Beta1) > EJB Attachment protocol mismatch > -------------------------------- > > Key: WFLY-7564 > URL: https://issues.jboss.org/browse/WFLY-7564 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > In both EJB client and server code, on method invocations where context data is sent, the sender writes the attachment count as a packed integer but the reader consumes it as an unsigned byte. This is not good. > The fix: > * In protocol 3 and higher, always read and write a packed integer > * In protocol 2 and lower, always read a packed integer but write a signed byte, failing if more than 127 attachments are present > Note that this is only temporary in the WFLY project as the server code should ultimately be moving to live in the ejb-client library. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2584) Domain Mode JMX access through the HostController

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2584?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-421 to WFCORE-2584: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2584 (was: WFLY-421) Issue Type: Feature Request (was: Task) Component/s: Domain Management JMX Remoting (was: JMX) (was: Remoting) Fix Version/s: (was: 11.0.0.Beta1) > Domain Mode JMX access through the HostController > ------------------------------------------------- > > Key: WFCORE-2584 > URL: https://issues.jboss.org/browse/WFCORE-2584 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, JMX, Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: JMX, investigation_required > > This task is first to review if this should be considered. > At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy. > The main motivation being to separate management and app traffic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-383) Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-383: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase > ----------------------------------------------------------------- > > Key: WFLY-383 > URL: https://issues.jboss.org/browse/WFLY-383 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid. > I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-487) Verify audit implications and required APIs

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-487: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Verify audit implications and required APIs > ------------------------------------------- > > Key: WFLY-487 > URL: https://issues.jboss.org/browse/WFLY-487 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 11.0.0.Beta1 > > > Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected. > i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-447) Connection Reauthentication and Security Propagation

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-447?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-447: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Connection Reauthentication and Security Propagation > ---------------------------------------------------- > > Key: WFLY-447 > URL: https://issues.jboss.org/browse/WFLY-447 > Project: WildFly > Issue Type: Task > Components: EJB, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 11.0.0.Beta1 > > > This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting. > This is to predominantly cover two major scenarios: - > - Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user. > - Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as. > The following document is building up the requirements and design considerations and decisions: - > https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPr... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-442: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Review of AccessController and PrivilegedAction use across AS7 > -------------------------------------------------------------- > > Key: WFLY-442 > URL: https://issues.jboss.org/browse/WFLY-442 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: investigation_required > Fix For: 11.0.0.Beta1 > > > The following needs reviewing across AS7: - > - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable). > - Use of AccessController even though there is no SecurityManager set. > - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED > - Utility methods with visibility too high. > - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction. > - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-421) Domain Mode JMX access through the HostController

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-421?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-421: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Domain Mode JMX access through the HostController > ------------------------------------------------- > > Key: WFLY-421 > URL: https://issues.jboss.org/browse/WFLY-421 > Project: WildFly > Issue Type: Task > Components: JMX, Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: JMX, investigation_required > Fix For: 11.0.0.Beta1 > > > This task is first to review if this should be considered. > At the moment access to JMX is provided through the remoting connector of each AS instance - this task is to consider if we should actually make it available through the host controller with the host controller acting as a proxy. > The main motivation being to separate management and app traffic. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-466: ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.Alpha1) > Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem. > -------------------------------------------------------------------------------- > > Key: WFLY-466 > URL: https://issues.jboss.org/browse/WFLY-466 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Beta1 > > > UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container. > This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017