Minor problem with alarm and races in lib/smbldap.c:smbldap_search_ext

[Richard Sharpe]

Hi,

There is another potential race in lib/smbldap.c:smbldap_search_ext,
although this time it is much less of a problem, it seems to me:

        got_alarm = 0;
        CatchSignal(SIGALRM, SIGNAL_CAST gotalarm_sig);
        alarm(lp_ldap_timeout());
        /* End setup timeout. */

        while (another_ldap_try(ldap_state, &rc, &attempts, endtime)) {
                rc = ldap_search_ext_s(ldap_state->ldap_struct, base, scope,
                                       utf8_filter,
                                       CONST_DISCARD(char **, attrs),
                                       attrsonly, sctrls, cctrls, &timeout,
                                       sizelimit, res);
                if (rc != LDAP_SUCCESS) {
                        char *ld_error = NULL;
                        int ld_errno;

                        ldap_get_option(ldap_state->ldap_struct,
                                        LDAP_OPT_ERROR_NUMBER, &ld_errno);

                        ldap_get_option(ldap_state->ldap_struct,
                                        LDAP_OPT_ERROR_STRING, &ld_error);
                        DEBUG(10, ("Failed search for base: %s, error: %d
(%s) "                                   "(%s)\n", base, ld_errno,
                                   ldap_err2string(rc),
                                   ld_error ? ld_error : "unknown"));
                        SAFE_FREE(ld_error);

                        if (ld_errno == LDAP_SERVER_DOWN) {
                                ldap_unbind(ldap_state->ldap_struct);
                                ldap_state->ldap_struct = NULL;
                        }
                }
        }

        SAFE_FREE(utf8_filter);

        /* Teardown timeout. */
        CatchSignal(SIGALRM, SIGNAL_CAST SIG_IGN);
        alarm(0);

It would seem possible that the arrival of the response and alarm are
coincident, but we will throw the response away.

I am not sure that this is worth spending much time on, however.

-- 
Regards,
Richard Sharpe