Re: [HACKERS] Server ignores contents of SASLInitialResponse - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Server ignores contents of SASLInitialResponse
Date
Msg-id CAB7nPqTqytzGryms4zJb8xZ98YkMs==3ntMBf-mvjNK_SqEj0g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Server ignores contents of SASLInitialResponse  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Server ignores contents of SASLInitialResponse  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Petr Jelinek
Date:
Subject: [HACKERS] Walsender timeouts and large transactions