On Mon, May 17, 2021 at 10:31 PM Chapman Flack <chap@anastigmatix.net> wrote:
>
> On 05/17/21 16:15, Magnus Hagander wrote:
> > The row is selected by the combination of username/database/ipaddress.
> > But you have to pick the minimum TLS version before the client has
> > sent that... Basically we have to make the choice long before we've
> > even started looking at pg_hba.
>
> Use the peer IP address to pre-filter the available pg_hba entries to
> those pertaining to that address ... choose a min protocol version that's
> the min specified among those ... then get the username and database name
> (by which point a protocol has been negotiated), then further filter the
> list down to those pertaining to that user and database and allowing that
> protocol version?
>
> Yes, clunky, but avoids a more ambitious redesign of pg_hba.
So you're saying that some entries int he parameter section would
depend on the db/user/ip combo and some would depend just on the ip?
That seems like an absolutely terrible idea to me, especially since
this is about security configuration. Way too easy to get wrong by
people who don't know how the internals work. People will *definitely*
set those parameter thinking that they can do it based on the db and
user as well.
> I'm not sure a more ambitious redesign would be a bad thing in principle;
> the pg_hba.conf syntax seems rather clunky and limiting to begin with,
> and I keep wondering why it isn't in shared tables or something. But
> I suppose a lot of external admin tools have some knowledge of it?
I think we'd either need a redesign of that, or a completely different
way of configuring pre-authentication settings.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/