Re: [PoC] Let libpq reject unexpected authentication requests

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: [PoC] Let libpq reject unexpected authentication requests
Date: 2022-09-16 14:56:20
Message-ID: ebf31cf7-b0af-7407-ada2-dda6d2767ba0@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08.09.22 20:18, Jacob Champion wrote:
> Sounds fair. "cleartext"? "plaintext"? "plain" (like SASL's PLAIN)?

> On the SASL front: In the back of my head I'd been considering adding
> a "sasl:" prefix to "scram-sha-256", so that we have a namespace for
> new SASL methods. That would also give us a jumping-off point in the
> future if we decide to add SASL method negotiation to the protocol.
> What do you think about that?

After thinking about this a bit more, I think it would be best if the
words used here match exactly with what is used in pg_hba.conf. That's
the only thing the user cares about: reject "password", reject "trust",
require "scram-sha-256", etc. How this maps to the protocol and that
some things are SASL or not is not something they have needed to care
about and don't really need to know for this. So I would suggest to
organize it that way.

Another idea: Maybe instead of the "!" syntax, use two settings,
require_auth and reject_auth? Might be simpler?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2022-09-16 15:08:59 Re: Query Jumbling for CALL and SET utility statements
Previous Message Julien Rouhaud 2022-09-16 14:36:12 Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.