Re: [PoC] Let libpq reject unexpected authentication requests - Mailing list pgsql-hackers

On Fri, Sep 16, 2022 at 7:56 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> On 08.09.22 20:18, Jacob Champion wrote:
> 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.

I tried that in v1, if you'd like to see what that ends up looking
like. As a counterexample, I believe `cert` auth looks identical to
`trust` on the client side. (The server always asks for a client
certificate even if it doesn't use it. Otherwise, this proposal would
probably have looked different.) And `ldap` auth is indistinguishable
from `password`, etc. In my opinion, how it maps to the protocol is
more honest to the user than how it maps to HBA, because the auth
request sent by the protocol determines your level of risk.

I also like `none` over `trust` because you don't have to administer a
server to understand what it means. That's why I was on board with
your proposal to change the name of `password`. And you don't have to
ignore the natural meaning of client-side "trust", which IMO means
"trust the server." There's opportunity for confusion either way,
unfortunately, but naming them differently may help make it clear that
they _are_ different.

This problem overlaps a bit with the last remaining TODO in the code.
I treat gssenc tunnels as satisfying require_auth=gss. Maybe that's
useful, because it kind of maps to how HBA treats it? But it's not
consistent with the TLS side of things, and it overlaps with
gssencmode=require, complicating the relationship with the new
sslcertmode.

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

Might be. If that means we have to handle the case where both are set
to something, though, it might make things harder.

We can error out if they conflict, which adds a decent but not huge
amount of complication. Or we can require that only one is set, which
is both easy and overly restrictive. But either choice makes it harder
to adopt a `reject password` default, as many people seem to be
interested in doing. Because if you want to override that default,
then you have to first unset reject_auth and then set require_auth, as
opposed to just saying require_auth=something and being done with it.
I'm not sure that's worth it. Thoughts?

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.

Thanks,
--Jacob