Re: Recognizing superuser in pg_hba.conf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Recognizing superuser in pg_hba.conf
Date: 2020-01-09 16:06:37
Message-ID: 8560.1578585997@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 9, 2020 at 10:06 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-01-09 16:10:10 Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
Previous Message Fabien COELHO 2020-01-09 16:00:23 Re: pgbench - refactor init functions with buffers