Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think we'd be best off to always override KRB5_KTNAME if we have a
>> nonempty krb_server_keyfile setting, so the attached proposed patch
>> makes both functions do it the same way. (I did not make an effort
>> to remove the depe
Greetings,
First, thanks a lot for working on all of this and improving things!
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I've got one last complaint about the backend GSS code: we are doing
> things randomly differently in the two places that install
> krb_server_keyfile as the active KRB5_KTNAME
I've got one last complaint about the backend GSS code: we are doing
things randomly differently in the two places that install
krb_server_keyfile as the active KRB5_KTNAME value. secure_open_gssapi()
sets KRB5_KTNAME unconditionally (and doesn't bother to check for error,
either, not a good thing
Here's a more complete patchset.
0001 is the same libpq fixes I posted before.
0002 fixes a collection of random server-side issues, including:
* The GSS encryption code figured it could just ereport(ERROR) or
ereport(FATAL) for unrecoverable errors. This seems entirely unsafe,
because elog.c w
Here's a draft patch for the libpq-side issues. The core of the
fix is to get rid of pqsecure_open_gss's clearing of allow_ssl_try,
and instead check whether GSS encryption is already enabled before
we try to enable SSL. While I was at it I also fixed the places
where we drop an attempted GSS con
I wrote:
> 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
At Thu, 24 Dec 2020 11:54:32 -0500, Tom Lane wrote in
> I wrote:
> > Kyotaro Horiguchi writes:
> >> 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 relevan
I wrote:
> Kyotaro Horiguchi writes:
>> 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 "hostgss
Kyotaro Horiguchi writes:
> At Wed, 23 Dec 2020 17:34:05 -0500, Tom Lane 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
At Wed, 23 Dec 2020 17:34:05 -0500, Tom Lane wrote in
> Oh ... wait a second. I've just managed to partially reproduce this
> report. Assume that we have a working Kerberos environment on both
If I kninit'ed and pg_hba.conf doesn't have a hostgssenc line and has
a hostssl line, I got the follo
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
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In the meantime, I did spot a code path that would explain the symptoms:
>> pqsecure_open_gss() clears allow_ssl_try sooner than it oughta. If
>> gss_wrap_size_limit() failed for some reason, we'd abandon the GSS
>> connection and
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> However: it is true (and undocumented, so we have at least a docs bug
> >> to fix) that v12-and-later libpq will try for GSS encryption first,
> >> and if it succeeds then it
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> However: it is true (and undocumented, so we have at least a docs bug
>> to fix) that v12-and-later libpq will try for GSS encryption first,
>> and if it succeeds then it will not consider using SSL, regardless of
>> sslmode. So ab
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > Gustavsson Mikael writes:
> >> So if i set gssencmode=disable on my pgsql-13 to postgres 13 server
> >> connection i get an SSL connection.
>
> > It looks like, if there is a credentials cache and gssencmode isn't
> > explicitly d
Hi.
At Thu, 17 Dec 2020 07:21:08 +, Gustavsson Mikael
wrote in
> But not from psql 13:
> $ /usr/pgsql-13/bin/psql -d postgres -Ukalle -hserver -W
> Password:
> psql: error: FATAL: no pg_hba.conf entry for host "nnn.nn.n.nnn", user
> "kalle", database "postgres", SSL off
> FATAL: no pg_hb
16 matches
Mail list logo
