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