Re: pgsql: Superuser can permit passwordless connections on postgres_fdw

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Superuser can permit passwordless connections on postgres_fdw
Date: 2019-12-20 19:42:22
Message-ID: 32150.1576870942@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

I wrote:
> This is a bit messier. But I think that the discrepancy is not
> really the fault of this patch: rather, it's a bug in the way the
> GSS support was put into libpq. I thought we had a policy that
> all builds would recognize all possible parameters and then
> perhaps fail later. Certainly the SSL parameters are implemented
> that way. The #if's disabling GSS stuff in PQconninfoOptions[]
> are just broken, according to that policy.

Concretely, I think we ought to do (and back-patch) the attached.

I notice in testing this that the "nosuper" business added by
6136e94dc is broken in more ways than what the buildfarm is
complaining about: it leaves the role around at the end of the
test. That's a HUGE violation of project policy, for security
reasons as well as the fact that it makes it impossible to run
"make installcheck" twice without getting different results.

regards, tom lane

Attachment Content-Type Size
accept-libpq-gss-parameters-unconditionally.patch text/x-diff 9.0 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2019-12-20 20:34:34 pgsql: libpq should expose GSS-related parameters even when not impleme
Previous Message Tom Lane 2019-12-20 19:04:37 Re: pgsql: Superuser can permit passwordless connections on postgres_fdw

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-20 20:10:17 pg_publication repetitious code
Previous Message Alvaro Herrera 2019-12-20 19:29:01 Re: range_agg