The slapi_ldap_bind() function does not properly check the bind operation results. It currently only calls ldap_parse_result() if returnedctrls was passed in by the caller. We need to call ldap_parse_result() even if we don't need to get the returned controls, as it's how we get the LDAP response code for the BIND operation. With the current code, slapi_ldap_bind() will end up returning 0 for a failed BIND operation if returnedctrls is not passed in.
In both openldap and mozldap it is safe to pass a NULL for the serverctrls parameter to ldap_parse_result. So code that does this: {{{ if (returnedctrls) { if ((rc = ldap_parse_result(ld, result, &rc, NULL, NULL, NULL, returnedctrls, 0)) != LDAP_SUCCESS) { / handle error / } } }}} can just do this instead {{{ if ((rc = ldap_parse_result(ld, result, &rc, NULL, NULL, NULL, returnedctrls, 0)) != LDAP_SUCCESS) { / handle error / } }}} There is no need to check for returnedctrls == NULL.
Also note that the return value of ldap_parse_result() is the same as the errcodep parameter - it is the ldap error code returned by the server.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=836386
attachment 0001-Ticket-399-slapi_ldap_bind-doesn-t-check-bind-result.patch
git merge ticket399 Updating a97f705..f43ed1d Fast-forward ldap/servers/slapd/ldaputil.c | 37 ++++++++++++++++++++++--------------- 1 files changed, 22 insertions(+), 15 deletions(-)
git push origin master Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.06 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git a97f705..f43ed1d master -> master
branch 389-ds-base-1.2.11 commit changeset:f43ed1d/389-ds-base Author: Mark Reynolds mreynolds@redhat.com Date: Fri Jun 29 13:46:45 2012 -0400
Added initial screened field value.
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.8
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/399
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.