Re: allow specifying direct role membership in pg_hba.conf - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allow specifying direct role membership in pg_hba.conf
Date
Msg-id 2190058.1621020926@sss.pgh.pa.us
Whole thread Raw
In response to Re: allow specifying direct role membership in pg_hba.conf  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Chapman Flack (chap@anastigmatix.net) wrote:
>> If pg_hba syntax changes are being entertained, I would love to be able
>> to set ssl_min_protocol_version locally in a hostssl rule.
>> Some clients at $work are stuck with ancient SSL libraries, but I would
>> much rather be able to weaken ssl_min_protocol_version just for them
>> than do it globally.

> This (unlike what was actually proposed) does seem like it'd be a useful
> improvement.  Not sure exaclty how it would work but I'm generally on
> board with the idea.

Seems like putting GUCs directly into pg_hba would be a mess.  Would
it be enough to tell people to use ALTER ROLE/DATABASE SET for this,
and then fix things so that we recheck the protocol version (and
possibly bail out) after absorbing those settings?

I can think of objections to this:

* If you actually want to tie the restriction to source IP addresses,
rather than users or databases, this doesn't get the job done.

* The authentication cycle would be completed (or at least mostly
so) before we bail out; so if the concern is about packet-sniffing
or MITM attacks, maybe this would expose too much.

But it does have the advantage of being something it seems like
we could get done easily.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: allow specifying direct role membership in pg_hba.conf
Next
From: Tom Lane
Date:
Subject: Re: PG 14 release notes, first draft