[PATCH] Remove unnecessary unbind in LDAP search+bind mode - Mailing list pgsql-hackers

From Anatoly Zaretsky
Subject [PATCH] Remove unnecessary unbind in LDAP search+bind mode
Date
Msg-id CALbq6kmJ-1+58df4B51ctPfTOSyPbY8Qi2=ct8oR=i4TamkUoQ@mail.gmail.com
Whole thread Raw
Responses Re: [PATCH] Remove unnecessary unbind in LDAP search+bind mode  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
Hi!

Comments in src/backend/libpq/auth.c [1] say:
(after successfully finding the final DN to check the user-supplied password against)
/* Unbind and disconnect from the LDAP server */
and later
/*
* Need to re-initialize the LDAP connection, so that we can bind to
* it with a different username.
*/

But the protocol actually permits multiple subsequent authentications ("binds" in LDAP parlance) over a single connection [2].
Moreover, inspection of the code revision history of mod_authnz_ldap, pam_ldap, Bugzilla, and MediaWiki LDAP authentication plugin, shows that they've been doing this bind-after-search over the same LDAP connection for ~20 years without any evidence of interoperability troubles.

(mod_authnz_ldap and pam_ldap are listed in the PostgreSQL documentation as examples of other software implementing this scheme. Bugzilla and MediaWiki are the original patch author's motivating examples [3])

Also it might be interesting to consider this note from the current revision of the protocol RFC [4]:
"The Unbind operation is not the antithesis of the Bind operation as the name implies. The naming of these operations are historical. The Unbind operation should be thought of as the "quit" operation."

So, it seems like the whole connection re-initialization thing was just a confusion caused by this very unfortunate "historical" naming, and can be safely removed, thus saving quite a few network round-trips, especially for the case of ldaps/starttls.

--
Best regards,
Anatoly Zaretsky
Attachment

pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Simplify some codes in pgoutput
Next
From: Thomas Munro
Date:
Subject: Re: refactoring basebackup.c