Re: Server ignores contents of SASLInitialResponse

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Server ignores contents of SASLInitialResponse
Date: 2017-05-25 15:36:20
Message-ID: CAB7nPqTqytzGryms4zJb8xZ98YkMs==3ntMBf-mvjNK_SqEj0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 25, 2017 at 10:52 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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

Attachment Content-Type Size
libpq-sasl-cleanup.patch application/octet-stream 1.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-05-25 15:52:50 Walsender timeouts and large transactions
Previous Message Robert Haas 2017-05-25 15:13:25 Re: [POC] hash partitioning