Horton

Re: Server ignores contents of SASLInitialResponse

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-05-25T15:36:20Z
Lists: pgsql-hackers

Attachments

On Thu, May 25, 2017 at 10:52 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Actually, I don't think that we are completely done here. Using the
> patch of upthread to enforce a failure on SASLInitialResponse, I see
> that connecting without SSL causes the following error:
> psql: FATAL:  password authentication failed for user "mpaquier"
> But connecting with SSL returns that:
> psql: duplicate SASL authentication request
>
> I have not looked at that in details yet, but it seems to me that we
> should not take pg_SASL_init() twice in the scram authentication code
> path in libpq for a single attempt.

Gotcha. This happens because of sslmode=prefer, on which
pqDropConnection is used to clean up the connection state. So it seems
to me that the correct fix is to move the cleanup of sasl_state to
pqDropConnection() instead of closePGconn(). Once I do so the failures
are correct, showing to the user two FATAL errors because of the two
attempts:
psql: FATAL:  password authentication failed for user "mpaquier"
FATAL:  password authentication failed for user "mpaquier"
-- 
Michael

Commits

  1. Clear auth context correctly when re-connecting after failed auth attempt.

  2. Fix double-free bug in GSS authentication.

  3. Abort authentication if the client selected an invalid SASL mechanism.

  4. Refactor libpq authentication request processing.