Re: Recognizing superuser in pg_hba.conf - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Recognizing superuser in pg_hba.conf
Date
Msg-id 8560.1578585997@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recognizing superuser in pg_hba.conf  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Recognizing superuser in pg_hba.conf  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 9, 2020 at 10:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What I'm basically objecting to is the pseudo-reservedness.  If we
>> don't want to dodge that with special syntax, we should dodge it
>> by making sure the keywords are actually reserved names.

> ...
> But I think I'm coming around to the view that we're making what ought
> to be a simple change complicated, and we should just not do that.

The problem is that we keep deciding that okay, it probably won't hurt
anybody if this particular thing-that-ought-to-be-a-reserved-word isn't
really reserved.  Your exercise in justifying that for "superuser" is
not unlike every other previous argument about this.  Sooner or later
that's going to fail, and somebody's going to have a security problem
because they didn't know that a particular name has magic properties
in a particular context.  (Which, indeed, maybe it didn't have when
they chose it.)  Claiming they should have known better isn't where
I want to be when that happens.

I don't want to keep going down that path.  These things are effectively
reserved words, and they need to act like reserved words, so that you
get an error if you misuse them.  Silently doing something else than
what (one reasonable reading of) a pg_hba.conf entry seems to imply
is *bad*.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench - refactor init functions with buffers
Next
From: Peter Eisentraut
Date:
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.