summaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvalidate.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-12-30 11:38:42 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-12-30 11:38:42 -0500
commit860fe27ee1e2a4a1c36c2f874c37656533cccce9 (patch)
treecbf3f64b956e54753feade50c056f67ea69b7d97 /src/backend/access/gist/gistvalidate.c
parente665769e6d1e84b6650f53ed297058fc11152f7f (diff)
downloadpostgresql-860fe27ee1e2a4a1c36c2f874c37656533cccce9.tar.gz
Fix up usage of krb_server_keyfile GUC parameter.
secure_open_gssapi() installed the krb_server_keyfile setting as KRB5_KTNAME unconditionally, so long as it's not empty. However, pg_GSS_recvauth() only installed it if KRB5_KTNAME wasn't set already, leading to a troubling inconsistency: in theory, clients could see different sets of server principal names depending on whether they use GSSAPI encryption. Always using krb_server_keyfile seems like the right thing, so make both places do that. Also fix up secure_open_gssapi()'s lack of a check for setenv() failure --- it's unlikely, surely, but security-critical actions are no place to be sloppy. Also improve the associated documentation. This patch does nothing about secure_open_gssapi()'s use of setenv(), and indeed causes pg_GSS_recvauth() to use it too. That's nominally against project portability rules, but since this code is only built with --with-gssapi, I do not feel a need to do something about this in the back branches. A fix will be forthcoming for HEAD though. Back-patch to v12 where GSSAPI encryption was introduced. The dubious behavior in pg_GSS_recvauth() goes back further, but it didn't have anything to be inconsistent with, so let it be. Discussion: https://postgr.es/m/2187460.1609263156@sss.pgh.pa.us
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions