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 |
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 |
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 |