[JBoss JIRA] (JGRP-2026) GroupRequest concurrency issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2026?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2026:
--------------------------------
Thi issue doesn't exist in 4.0, removing 4.0 from the target fix set. I'll fix this on the 3.6 branch by simply moving the {{checkCompletion()}} into the lock scope.
> GroupRequest concurrency issue
> ------------------------------
>
> Key: JGRP-2026
> URL: https://issues.jboss.org/browse/JGRP-2026
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.9, 4.0
>
>
> {{GroupRequest.responsesComplete()}} is supposed to be called only while holding the lock ({{@GuardedBy("lock")}}). But {{GroupRequest.receiveResponse()}} calls {{Request.checkCompletion()}} outside the lock, which then calls {{GroupRequest.responsesComplete()}}.
> Because this happens outside the lock, there is no happens-before relationship, and a thread can notify the request listener after another seeing the {{numReceived}} incremented by another thread, but without seeing the {{Rsp.value}} set by that other thread.
> {noformat}
> 23:22:21,328 TRACE (transport-thread-MultiNodeDistributedTest-NodeB-p8-t6) [JGroupsTransport] dests=null, command=CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=MultiNodeDistributedTest-NodeB-28202, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}, mode=SYNCHRONOUS, timeout=240000
> 23:22:21,329 TRACE (transport-thread-MultiNodeDistributedTest-NodeB-p8-t6) [MessageDispatcher] real_dests=[MultiNodeDistributedTest-NodeC-19310, MultiNodeDistributedTest-NodeD-7096]
> 23:22:21,351 TRACE (remote-thread-MultiNodeDistributedTest-NodeD-p26-t3) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=...} for command CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}
> 23:22:21,361 TRACE (remote-thread-MultiNodeDistributedTest-NodeC-p18-t6) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=...} for command CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}
> 23:22:21,418 TRACE (remote-thread-MultiNodeDistributedTest-NodeD-p26-t3) [UNICAST3] MultiNodeDistributedTest-NodeD-7096 --> DATA(MultiNodeDistributedTest-NodeB-28202: #24, conn_id=1)
> 23:22:21,418 TRACE (remote-thread-MultiNodeDistributedTest-NodeC-p18-t6) [UNICAST3] MultiNodeDistributedTest-NodeC-19310 --> DATA(MultiNodeDistributedTest-NodeB-28202: #68, conn_id=1)
> 23:22:21,427 TRACE (OOB-2,MultiNodeDistributedTest-NodeB-28202) [UNICAST3] MultiNodeDistributedTest-NodeB-28202: delivering MultiNodeDistributedTest-NodeD-7096#24
> 23:22:21,431 TRACE (OOB-1,MultiNodeDistributedTest-NodeB-28202) [UNICAST3] MultiNodeDistributedTest-NodeB-28202: delivering MultiNodeDistributedTest-NodeC-19310#68
> 23:22:21,455 TRACE (OOB-2,MultiNodeDistributedTest-NodeB-28202) [JGroupsTransport] Responses: [sender=MultiNodeDistributedTest-NodeC-19310, received=false, suspected=false]
> [sender=MultiNodeDistributedTest-NodeD-7096, retval=SuccessfulResponse{responseValue=...} , received=true, suspected=false]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2026) GroupRequest concurrency issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2026?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2026:
---------------------------
Fix Version/s: 3.6.9
4.0
> GroupRequest concurrency issue
> ------------------------------
>
> Key: JGRP-2026
> URL: https://issues.jboss.org/browse/JGRP-2026
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.9, 4.0
>
>
> {{GroupRequest.responsesComplete()}} is supposed to be called only while holding the lock ({{@GuardedBy("lock")}}). But {{GroupRequest.receiveResponse()}} calls {{Request.checkCompletion()}} outside the lock, which then calls {{GroupRequest.responsesComplete()}}.
> Because this happens outside the lock, there is no happens-before relationship, and a thread can notify the request listener after another seeing the {{numReceived}} incremented by another thread, but without seeing the {{Rsp.value}} set by that other thread.
> {noformat}
> 23:22:21,328 TRACE (transport-thread-MultiNodeDistributedTest-NodeB-p8-t6) [JGroupsTransport] dests=null, command=CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=MultiNodeDistributedTest-NodeB-28202, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}, mode=SYNCHRONOUS, timeout=240000
> 23:22:21,329 TRACE (transport-thread-MultiNodeDistributedTest-NodeB-p8-t6) [MessageDispatcher] real_dests=[MultiNodeDistributedTest-NodeC-19310, MultiNodeDistributedTest-NodeD-7096]
> 23:22:21,351 TRACE (remote-thread-MultiNodeDistributedTest-NodeD-p26-t3) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=...} for command CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}
> 23:22:21,361 TRACE (remote-thread-MultiNodeDistributedTest-NodeC-p18-t6) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=...} for command CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}
> 23:22:21,418 TRACE (remote-thread-MultiNodeDistributedTest-NodeD-p26-t3) [UNICAST3] MultiNodeDistributedTest-NodeD-7096 --> DATA(MultiNodeDistributedTest-NodeB-28202: #24, conn_id=1)
> 23:22:21,418 TRACE (remote-thread-MultiNodeDistributedTest-NodeC-p18-t6) [UNICAST3] MultiNodeDistributedTest-NodeC-19310 --> DATA(MultiNodeDistributedTest-NodeB-28202: #68, conn_id=1)
> 23:22:21,427 TRACE (OOB-2,MultiNodeDistributedTest-NodeB-28202) [UNICAST3] MultiNodeDistributedTest-NodeB-28202: delivering MultiNodeDistributedTest-NodeD-7096#24
> 23:22:21,431 TRACE (OOB-1,MultiNodeDistributedTest-NodeB-28202) [UNICAST3] MultiNodeDistributedTest-NodeB-28202: delivering MultiNodeDistributedTest-NodeC-19310#68
> 23:22:21,455 TRACE (OOB-2,MultiNodeDistributedTest-NodeB-28202) [JGroupsTransport] Responses: [sender=MultiNodeDistributedTest-NodeC-19310, received=false, suspected=false]
> [sender=MultiNodeDistributedTest-NodeD-7096, retval=SuccessfulResponse{responseValue=...} , received=true, suspected=false]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2026) GroupRequest concurrency issue
by Dan Berindei (JIRA)
Dan Berindei created JGRP-2026:
----------------------------------
Summary: GroupRequest concurrency issue
Key: JGRP-2026
URL: https://issues.jboss.org/browse/JGRP-2026
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.8
Reporter: Dan Berindei
Assignee: Bela Ban
{{GroupRequest.responsesComplete()}} is supposed to be called only while holding the lock ({{@GuardedBy("lock")}}). But {{GroupRequest.receiveResponse()}} calls {{Request.checkCompletion()}} outside the lock, which then calls {{GroupRequest.responsesComplete()}}.
Because this happens outside the lock, there is no happens-before relationship, and a thread can notify the request listener after another seeing the {{numReceived}} incremented by another thread, but without seeing the {{Rsp.value}} set by that other thread.
{noformat}
23:22:21,328 TRACE (transport-thread-MultiNodeDistributedTest-NodeB-p8-t6) [JGroupsTransport] dests=null, command=CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=MultiNodeDistributedTest-NodeB-28202, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}, mode=SYNCHRONOUS, timeout=240000
23:22:21,329 TRACE (transport-thread-MultiNodeDistributedTest-NodeB-p8-t6) [MessageDispatcher] real_dests=[MultiNodeDistributedTest-NodeC-19310, MultiNodeDistributedTest-NodeD-7096]
23:22:21,351 TRACE (remote-thread-MultiNodeDistributedTest-NodeD-p26-t3) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=...} for command CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}
23:22:21,361 TRACE (remote-thread-MultiNodeDistributedTest-NodeC-p18-t6) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=...} for command CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=4}
23:22:21,418 TRACE (remote-thread-MultiNodeDistributedTest-NodeD-p26-t3) [UNICAST3] MultiNodeDistributedTest-NodeD-7096 --> DATA(MultiNodeDistributedTest-NodeB-28202: #24, conn_id=1)
23:22:21,418 TRACE (remote-thread-MultiNodeDistributedTest-NodeC-p18-t6) [UNICAST3] MultiNodeDistributedTest-NodeC-19310 --> DATA(MultiNodeDistributedTest-NodeB-28202: #68, conn_id=1)
23:22:21,427 TRACE (OOB-2,MultiNodeDistributedTest-NodeB-28202) [UNICAST3] MultiNodeDistributedTest-NodeB-28202: delivering MultiNodeDistributedTest-NodeD-7096#24
23:22:21,431 TRACE (OOB-1,MultiNodeDistributedTest-NodeB-28202) [UNICAST3] MultiNodeDistributedTest-NodeB-28202: delivering MultiNodeDistributedTest-NodeC-19310#68
23:22:21,455 TRACE (OOB-2,MultiNodeDistributedTest-NodeB-28202) [JGroupsTransport] Responses: [sender=MultiNodeDistributedTest-NodeC-19310, received=false, suspected=false]
[sender=MultiNodeDistributedTest-NodeD-7096, retval=SuccessfulResponse{responseValue=...} , received=true, suspected=false]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6372) Flagging of invalid login credential for datasource is inconsistent.
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFLY-6372:
----------------------------------------
Summary: Flagging of invalid login credential for datasource is inconsistent.
Key: WFLY-6372
URL: https://issues.jboss.org/browse/WFLY-6372
Project: WildFly
Issue Type: Bug
Reporter: Bartosz Baranowski
Assignee: Jason Greene
There are multiple parts to this
(1) If the security-domain is defined for a datasource and the password is invalid, an error is reported in the console which is expected
<datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
<connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
<driver>oracle</driver>
<security>
<security-domain>encryptedPassword2</security-domain>
</security>
</datasource>
(2) If the 'password' for the datasource is invalid no error is reported in the console log at startup e.g
<datasource jndi-name="java:/DefaultDS2" pool-name="DefaultDS2" enabled="true" use-java-context="true">
<connection-url>jdbc:oracle:thin:@hostname:1521:ora1</connection-url>
<driver>oracle</driver>
<security>
<user-name>user</user-name>
<password>passwd</password>
</security>
</datasource>
3. Whether or not you use a security-domain for a datasource, an invalid 'username' doesn't get flagged in the console.
Actual results:
Expected results:
Invalid username and password should be flagged as login errors in the console log.
It shouldn't make a difference whether or not you use security-credentials
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6371) LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFLY-6371:
----------------------------------------
Summary: LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
Key: WFLY-6371
URL: https://issues.jboss.org/browse/WFLY-6371
Project: WildFly
Issue Type: Bug
Reporter: Bartosz Baranowski
Assignee: Jason Greene
In case when LdapExtLoginModule is correctly configured for authentication, but its attributes rolesCtxDN and roleFilter are not set, then authentication with correct username and password leads to FailedLoginException.
Expected behavior is that user should be authenticated but no roles should be assigned to them.
Possible EAP configuration:
<security-domain name="ldap">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
<module-option name="baseFilter" value="(uid=
{0})"/>
<module-option name="bindDN" value="uid=admin,ou=system"/>
<module-option name="baseCtxDN" value="ou=People,o=MyOrg,o=primary,dc=jboss,dc=org"/>
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
<module-option name="java.naming.security.authentication" value="simple"/>
<module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
<module-option name="bindCredential" value="secret"/>
</login-module>
</authentication>
</security-domain>
In case when these attributes are added
<module-option name="rolesCtxDN" value="ou=Roles,o=MyOrg,o=primary,dc=jboss,dc=org"/>
<module-option name="roleFilter" value="(member={0}
)"/>
then user is correctly authenticated (even in case when no role is assigned to them).
It is caused by internal NPE thrown from method rolesSearch in LdapExtLoginModule class on line:
results = ldapCtx.search(rolesCtxDN, roleFilter, filterArgs, constraints);
DEBUG [org.jboss.security] (default task-2) PBOX000206: Login failure: javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:284)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:350)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:338)
at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:148)
at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:82)
at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month