Re: Recognizing superuser in pg_hba.conf

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > On Thu, Jan 2, 2020 at 15:50 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> To cover the proposed functionality, you'd still need some way to
> >> select not-superuser. So I don't think this fully answers the need
> >> even if we wanted to do it.
>
> > Sorry- why do we need that..? The first match for a pg_hba line wins, so
> > you can define all the access methods that superuser accounts are allowed
> > to use first, then a “reject” line for superuser accounts, and then
> > whatever else you want after that.
>
> Seems kind of awkward. Or more to the point: you can already do whatever
> you want in pg_hba.conf, as long as you're willing to be verbose enough
> (and, perhaps, willing to maintain group memberships to fit your needs).

Sure it's awkward, but it's how people actually deal with these things
today. I'm not against improving on that situation but I also don't
hear tons of complaints about it either, so I do think we should be
thoughtful when it comes to making changes here.

> The discussion here, IMO, is about offering useful shorthands.

In general, I'm alright with that idea, but I do want to make sure we're
really being thoughtful when it comes to inventing new syntax that will
only work in this one place and will have to be handled specially by any
tools or anything that wants to generate or look at this.

What are we going to have be displayed through pg_hba_file_rules() for
this '!role' or whatever else, in the 'user_name' column? (Also, ugh,
I find calling that column 'user_name' mildly offensive considering that
function was added well after roles, and it's not like it really meant
'user name' even before then..).

Yes, I'm sure we could just have it be the text '!role' and make
everyone who cares have to parse out that field, in SQL, to figure out
who it really applies to and basically just make everyone deal with it
but I remain skeptical about if it's really a particularly good
approach.

> So a facility like "!role" seems potentially useful. Maybe it's not
> really, but I don't think we should reject it just because there's
> a verbose and non-obvious way to get the same result.

I don't agree that it's "non-obvious" that if you have a config file
where "first match wins" that things which don't match the first line
are, by definition, NOT whatever that first line was and then fall
through to the next, where you could use 'reject' if you want. In fact,
I've always kinda figured that's what 'reject' was for, though I'll
admit that it's been around for far longer than I've been involved in
the project (sadly, I hadn't discovered PG yet back in 1998).

Thanks,

Stephen