From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Gustavsson Mikael <mikael.gustavsson@smhi.se>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
Cc: Svensson Peter <peter.svensson@smhi.se>
Subject: Re: Problem with ssl and psql in Postgresql 13
Date: Wed, 23 Dec 2020 17:34:05 -0500
Message-ID: <742641.1608762845@sss.pgh.pa.us> (raw)
In-Reply-To: <740093.1608760567@sss.pgh.pa.us>
References: <89909.1608222331@sss.pgh.pa.us>
<61e2a65bbc2f47d297a6f3cdac2cc6cc@smhi.se>
<d3ab9042bce34aae85d323d69e3ee430@smhi.se>
<169637.1608321770@sss.pgh.pa.us>
<c347c62b507743ceac0aaebd0ccff533@smhi.se>
<de4dc5a4f22d43a28300bccb70d99db6@smhi.se>
<723586.1608740901@sss.pgh.pa.us>
<737386.1608757126@sss.pgh.pa.us>
<20201223211448.GR27507@tamriel.snowman.net>
<738715.1608758847@sss.pgh.pa.us>
<20201223214534.GS27507@tamriel.snowman.net>
<740093.1608760567@sss.pgh.pa.us>
Oh ... wait a second. I've just managed to partially reproduce this
report. Assume that we have a working Kerberos environment on both
ends. Then libpq will establish a connection with GSS encryption
and continue on with the usual PG authentication exchange. If that
part fails, then this logic (fe_connect.c around line 3350):
/*
* If gssencmode is "prefer" and we're using GSSAPI, retry
* without it.
*/
if (conn->gssenc && conn->gssencmode[0] == 'p')
{
/* postmaster expects us to drop the connection */
conn->try_gss = false;
pqDropConnection(conn, true);
conn->status = CONNECTION_NEEDED;
goto keep_going;
}
drops the connection and tries again without GSS. But *we already
cleared allow_ssl_try*, in pqsecure_open_gss, so the next try will
not bother with SSL either.
So this directly explains the original report: if the only applicable
pg_hba.conf entry is "hostssl", right here is where libpq will see
that error, and it will go around and fail again because the next
try uses neither GSS nor SSL.
However, in the tests Mikael ran after backing that pg_hba.conf entry
off to just "host", pg_hba wouldn't have caused an authentication-stage
failure, so it's not so clear why we'd have looped back at this step.
We'd need to explain the later cases to have a full theory. It's
plenty plausible that something else caused an auth-stage failure,
but if so, why would the second GSS-free try work?
In any case, that allow_ssl_try reset in pqsecure_open_gss is definitely
even more broken than I thought before. I think we need to rejigger the
state machine so that it doesn't do that at all, but instead skips SSL
establishment when GSS is already active via an explicit test, rather
than munging the state variables.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net, mikael.gustavsson@smhi.se, magnus@hagander.net, horikyota.ntt@gmail.com, peter.svensson@smhi.se
Subject: Re: Problem with ssl and psql in Postgresql 13
In-Reply-To: <742641.1608762845@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox