Re: [PoC] Let libpq reject unexpected authentication requests
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Jacob Champion <jchampion@timescale.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Michael Paquier <michael@paquier.xyz>,
"David G. Johnston" <david.g.johnston@gmail.com>
Date: 2022-09-21T22:36:41Z
Lists: pgsql-hackers
On 21.09.22 17:33, Jacob Champion wrote:
> On Fri, Sep 16, 2022 at 1:29 PM Jacob Champion <jchampion@timescale.com> wrote:
>> I'm happy to implement proofs of concept for that, or any other ideas,
>> given the importance of getting this "right enough" the first time.
>> Just let me know.
>
> v8 rebases over the postgres_fdw HINT changes; there are no functional
> differences.
So let's look at the two TODO comments you have:
* TODO: how should !auth_required interact with an incomplete
* SCRAM exchange?
What specific combination of events are you thinking of here?
/*
* If implicit GSS auth has already been performed via GSS
* encryption, we don't need to have performed an
* AUTH_REQ_GSS exchange.
*
* TODO: check this assumption. What mutual auth guarantees
* are made in this case?
*/
I don't understand the details involved here, but I would be surprised
if this assumption is true. For example, does GSS encryption deal with
user names and a user name map? I don't see how these can be
equivalent. In any case, it seems to me that it would be safer to *not*
make this assumption at first and then have someone more knowledgeable
make the argument that it would be safe.
Commits
-
libpq: Add sslcertmode option to control client certificates
- 36f40ce2dc66 16.0 landed
-
Rewrite error message related to sslmode in libpq
- bcaa1fafc82f 16.0 landed
-
libpq: Add support for require_auth to control authorized auth methods
- 3a465cc6783f 16.0 landed
-
Run pgindent on libpq's fe-auth.c, fe-auth-scram.c and fe-connect.c
- b6dfee28f2b4 16.0 landed