ldap_unbind() & co fail without doing anything if a critical client control is set with ldap_set_option() or passed to ldap_unbind_ext_s(). This seems wrong, since ldap_unbind() has always been documented as the way to both close the connection and free the LDAP structure.
Yet if some code does set a critical client control, that might be a hack to get exactly this functionality: Temporarily protect the LDAP* from being destroyed by some other code.
Server controls do not prevent the Unbind. RFC 4511 says the criticality field MUST be ignored for Unbind controls. But that's in the protocol. Client controls are an LDAP API invention.
I don't know which solution to pick. Opinions?
Maybe we should deprecate ldap_unbind... calls now that we have ldap_destroy(). That function also sends an Unbind if it can. But that doesn't affect existing code using ldap_unbind...().
LDAPControl ctrl = {"1.2.3.4", {0,""}, 1}, *ctrls[] = {&ctrl, NULL}; LDAP *ld = ldap_open("ldap", LDAP_PORT); ldap_set_option(ld, LDAP_OPT_CLIENT_CONTROLS, ctrls); ldap_unbind_ext_s(ld, NULL, NULL); /* Connection remains open here... */ sleep(999);
Hallvard B Furuseth wrote:
ldap_unbind() & co fail without doing anything if a critical client control is set with ldap_set_option() or passed to ldap_unbind_ext_s().
Not sure whether it's related: But I have problems sending unbind with python-ldap via ldap_unbind_ext() when using a persistent search control with Novell eDirectory. Without the control it's behaving as expected. But it also may be related to eDirectory misbehaving...it's hard to track this down...
There are various other reports about unbind hanging by python-ldap users e.g. with MS AD some of which might be related to GnuTLS being used.
Also I suspect ITS#6928 to be related to unbind (consumer is Debian build of OpenLDAP linked to GnuTLS). I regard this as possibility for a DoS attack on a provider server. (No response to this ITS so far...)
Ciao, Michael.
-
Hallvard B Furuseth -
Michael Ströder