FO: Check server validity before setting statussssd-1_8_5

The list of resolved servers is allocated on the back end context and
kept in the fo_service structure. However, a single request often
resolves a server and keeps a pointer until the end of a request and
only then gives feedback about the server based on the request result.

This presents a big race condition in case the SRV resolution is used.
When there are requests coming in in parallel, it is possible that an
incoming request will invalidate a server until another request that
holds a pointer to the original server is able to give a feedback.

This patch simply checks if a server is in the list of servers
maintained by a service before reading its status.

https://fedorahosted.org/sssd/ticket/1364

1 files changed, 3 insertions, 1 deletions

diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c
index 734249ced..08502c147 100644
--- a/src/providers/ldap/ldap_auth.c
+++ b/src/providers/ldap/ldap_auth.c
@@ -590,6 +590,7 @@ static void auth_connect_done(struct tevent_req *subreq)
         if (state->srv) {
             /* mark this server as bad if connection failed */
             be_fo_set_port_status(state->ctx->be,
+                                  state->sdap_service->name,
                                   state->srv, PORT_NOT_WORKING);
         }
         if (ret == ETIMEDOUT) {
@@ -602,7 +603,8 @@ static void auth_connect_done(struct tevent_req *subreq)
         tevent_req_error(req, ret);
         return;
     } else if (state->srv) {
-        be_fo_set_port_status(state->ctx->be, state->srv, PORT_WORKING);
+        be_fo_set_port_status(state->ctx->be, state->sdap_service->name,
+                              state->srv, PORT_WORKING);
     }
 
     ret = get_user_dn(state, state->ctx->be->sysdb, state->ctx->opts,