Re: Problem with ssl and psql in Postgresql 13
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Gustavsson Mikael <mikael.gustavsson@smhi.se>,
Magnus Hagander <magnus@hagander.net>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
"pgsql-general@postgresql.org" <pgsql-general@postgresql.org>,
Svensson Peter <peter.svensson@smhi.se>
Date: 2020-12-27T22:32:54Z
Lists: pgsql-general
Attachments
- 0001-fix-libpq-gss-bugs.patch (text/x-diff) patch 0001
- 0002-fix-server-gss-issues.patch (text/x-diff) patch 0002
- 0003-remove-authtype-restriction.patch (text/x-diff) patch 0003
- 0004-gss-documentation-fixes.patch (text/x-diff) patch 0004
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
Commits
-
Fix up usage of krb_server_keyfile GUC parameter.
- 861e967176e9 13.2 landed
- 860fe27ee1e2 14.0 landed
- 3ca19490b4f8 12.6 landed
-
Improve log messages related to pg_hba.conf not matching a connection.
- d05e14d786ac 13.2 landed
- 7ed616f818f0 12.6 landed
- 3995c424984e 14.0 landed
-
Fix assorted issues in backend's GSSAPI encryption support.
- c1c88bf03e1e 13.2 landed
- 622ae4621ece 14.0 landed
- 4cfdd8a47a9e 12.6 landed
-
Fix bugs in libpq's GSSAPI encryption support.
- ff6ce9a3a691 14.0 landed
- b3a5bf719cf7 12.6 landed
- 06b844c2b8d3 13.2 landed