Re: allow specifying direct role membership in pg_hba.conf

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow specifying direct role membership in pg_hba.conf
Date: 2021-05-18 01:31:23
Message-ID: 60A318EB.3090702@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/17/21 21:19, Chapman Flack wrote:
> This makes twice in a row that I've failed to see how.
>
> If you go through the entries, in order, and simply prune from the list
> the ones you can already prove would never apply to this connection, how
> does that break the ordering principle?

Ok, I see how what I proposed looks out-of-order just in that it lets the
initial TLS negotiation be influenced by the minimum version over all
potentially-applicable entries.

But that's just an optimization anyway. The same ultimate effect would be
achieved by unconditionally allowing anything back to TLSv1 to be negotiated
at SSLRequest time, and then (processing the entries in order as always)
rejecting the connection if the first one that could apply expects a higher
protocol version.

The pre-scan and use of the minimum version encountered has only the effect
of fast-failing a TLS negotiation for a version that won't possibly succeed.

Regards,
-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-05-18 01:49:39 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Previous Message David Rowley 2021-05-18 01:27:48 Re: Skip partition tuple routing with constant partition key