From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: sfrost@snowman.net
Cc: mikael.gustavsson@smhi.se
Cc: magnus@hagander.net
Cc: pgsql-general@postgresql.org
Cc: peter.svensson@smhi.se
Subject: Re: Problem with ssl and psql in Postgresql 13
Date: Wed, 23 Dec 2020 22:22:21 -0500
Message-ID: <755331.1608780141@sss.pgh.pa.us> (raw)
In-Reply-To: <20201224.120520.788085853846287470.horikyota.ntt@gmail.com>
References: <20201223214534.GS27507@tamriel.snowman.net>
<740093.1608760567@sss.pgh.pa.us>
<742641.1608762845@sss.pgh.pa.us>
<20201224.120520.788085853846287470.horikyota.ntt@gmail.com>
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Wed, 23 Dec 2020 17:34:05 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
>> 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.
> In the hostssl case, there are two errors emitted on the server side:
> [24494] FATAL: no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
> [24495] FATAL: no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
> However, the first line is bogus. It should be like the following.
> FATAL: no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", GSSENC on
> FATAL: no pg_hba.conf entry for host "192.168.56.101", user "horiguti", database "postgres", SSL off
> The attached the first patch does that.
+1, it seems like a clear oversight that the GSSENC patches didn't adjust
these messages. The reason SSL state is mentioned is that it's relevant
to which pg_hba entry gets chosen; and once we invented "hostgssenc"
entries, GSSENC state is also relevant. I'm not sure though if we want
to spell it like "GSSENC on", or "GSS encryption on", or something else.
Stephen or other onlookers, any comments?
>> 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?
> Does my expample above works?
I don't see how it explains Mikael's later tests, but maybe I'm missing
something.
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, horikyota.ntt@gmail.com, sfrost@snowman.net, mikael.gustavsson@smhi.se, magnus@hagander.net, peter.svensson@smhi.se
Subject: Re: Problem with ssl and psql in Postgresql 13
In-Reply-To: <755331.1608780141@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