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

  1. libpq: Add sslcertmode option to control client certificates

  2. Rewrite error message related to sslmode in libpq

  3. libpq: Add support for require_auth to control authorized auth methods

  4. Run pgindent on libpq's fe-auth.c, fe-auth-scram.c and fe-connect.c