From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Gustavsson Mikael <mikael(dot)gustavsson(at)smhi(dot)se>, Magnus Hagander <magnus(at)hagander(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Svensson Peter <peter(dot)svensson(at)smhi(dot)se> |
Subject: | Re: Problem with ssl and psql in Postgresql 13 |
Date: | 2020-12-27 22:32:54 |
Message-ID: | 1528843.1609108374@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 will try to send the error message to the client,
likely re-triggering the same error and leading to infinite recursion.
Even if that doesn't happen, we might have sent a partial packet
to the client meaning that protocol synchronization is lost. The
right thing to do is like what the SSL encryption code has long done:
log the error at COMMERROR level and then return errno = ECONNRESET
to shut things down.
* Fix sloppiness about whether pg_GSS_error()'s message parameter
is already translated or not. (BTW, I'm a bit inclined to remove
pg_GSS_error()'s elevel parameter altogether and hardwire it as
COMMERROR, thus removing a bug temptation and making it more like the
similarly-named frontend function. I didn't pull the trigger on that
here, though.)
* I really didn't like that we had the postmaster allocating the
port->gss struct (and committing hara-kiri if it could not).
Admittedly, the struct is not so large that an OOM failure is
likely, but it's just dumb to make the postmaster allocate a
struct it has zero use for. I moved that allocation to the code
that actually needs it, GSSAPI encryption or auth startup.
* That also allows fixing a bug I noticed earlier, that the
"connection authorized" log message fails to mention GSS if we are
only using GSS for encryption without invoking GSS auth. We can
use whether or not port->gss is non-null to figure out whether
the GSS clause of the message should appear. (This is related to,
but distinct from, the pg_hba.conf-related log message fixes
discussed upthread. I've not included those changes here, but
they're still on the table.)
* BackendStatusShmemSize failed to account for GSS-related space.
With large max_connections this could make a serious dent in our
shared-memory slop space.
* Various places knew more than they needed to about whether
port->gss->auth being set is equivalent to port->gss->princ being set.
* Remove long-dead call of secure_close() in postmaster's
ConnFree subroutine.
The 0003 patch removes the restriction I griped of earlier about
which auth methods can be used on a GSS-encrypted connection.
I made that a separate patch just in case it's controversial.
Finally, 0004 tries to improve the documentation in this area.
Some of that is reflective of 0003, but most of it is just
cleanup.
I propose to back-patch all of this as far as v12.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
0001-fix-libpq-gss-bugs.patch | text/x-diff | 3.2 KB |
0002-fix-server-gss-issues.patch | text/x-diff | 17.9 KB |
0003-remove-authtype-restriction.patch | text/x-diff | 1.7 KB |
0004-gss-documentation-fixes.patch | text/x-diff | 16.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | B Anderson | 2020-12-28 03:01:43 | Re: Postgres read jsonb content from stdin |
Previous Message | Adrian Klaver | 2020-12-27 15:52:21 | Re: alter system command |