From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PoC] Let libpq reject unexpected authentication requests |
Date: | 2022-06-23 17:33:57 |
Message-ID: | CAAWbhmjOVfRr=Pjp3ZjcVLnHoXBXvn=hcjC2JV02cXB71uWjWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 22, 2022 at 5:56 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> That just makes me want to not implement OR'ing...
>
> The existing set of individual parameters doesn't work as an API for try-and-fallback.
>
> Something like would be less problematic when it comes to setting multiple related options:
>
> --auth-try "1;sslmode=require;channel_binding=require;method=scram-sha-256;sslcert=/tmp/machine.cert;sslkey=/tmp/machine.key"
> --auth-try "2;sslmode=require;method=cert;sslcert=/tmp/me.cert;sslkey=/tmp/me.key"
> --auth-try "3;sslmode=prefer;method=md5"
I think that's a fair point, and your --auth-try example definitely
illustrates why having require_auth try to do everything is probably
not a viable strategy. My arguments for keeping OR in spite of that
are
- the default is effectively an OR of all available methods (plus "none");
- I think NOT is a important case in practice, which is effectively a
negative OR ("anything but this/these"); and
- not providing an explicit, positive OR to complement the above seems
like it would be a frustrating user experience once you want to get
just a little bit more creative.
It's also low-hanging fruit that doesn't require multiple connections
to the server per attempt (which I think your --auth-try proposal
might, if I understand it correctly).
> Absent that radical idea, require_auth probably shouldn't change any behavior that exists today without having specified require_auth and having the chosen method happen anyway. So whatever happens today with an md5 password prompt while channel_binding is set to require (not in the mood right now to figure out how to test that on a compiled against HEAD instance).
I think the newest tests in v3 should enforce that, but let me know if
I've missed something.
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-06-23 17:45:07 | Re: allow specifying action when standby encounters incompatible parameter settings |
Previous Message | Nathan Bossart | 2022-06-23 17:15:52 | Re: O(n) tasks cause lengthy startups and checkpoints |