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 5526.1578582366@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recognizing superuser in pg_hba.conf  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Recognizing superuser in pg_hba.conf  (Stephen Frost <sfrost@snowman.net>)
Re: Recognizing superuser in pg_hba.conf  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Wed, 8 Jan 2020 at 23:55, Vik Fearing <vik.fearing@2ndquadrant.com>
> wrote:
>> What is being proposed is what is in the Subject and the original
>> patch.  The other patch is because Tom didn't like "the continuing creep
>> of pseudo-reserved database and user names" so I wrote a patch to mark
>> such reserved names and rebased my original patch on top of it.  Only
>> the docs changed in the rebase.  The original patch (or its rebase) is
>> what I am interested in.

> Hopefully there will be no danger of me gaining access if I have a crafted
> rolename?
> postgres=# create role "&backdoor";
> CREATE ROLE

Well, the existence of such a role name wouldn't by itself cause any
change in the way that pg_hba.conf is parsed.  If you could then
persuade a superuser to insert a pg_hba.conf line that is trying
to match your username, the line might do something else than what the
superuser expected, which is bad.  But the *exact* same hazard applies
to proposals based on inventing pseudo-reserved keywords (by which
I mean things that look like names, but aren't reserved words, so that
somebody could create a role name matching them).  Either way, an
uninformed superuser could be tricked.

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.  In other
words, add a "pg_" prefix, as somebody else suggested upthread.
I don't personally find that prettier than a punctuation prefix,
but I can live with it if other people do.

BTW, although that solution works for the immediate need of
keywords that have to be distinguished from role names, it doesn't
currently scale to keywords for the database column, because we
don't treat "pg_" as a reserved prefix for database names:

regression=# create role pg_zit;
ERROR:  role name "pg_zit" is reserved
DETAIL:  Role names starting with "pg_" are reserved.
regression=# create database pg_zit;
CREATE DATABASE

Should we do so, or wait till there's an immediate need to?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
Next
From: Konstantin Knizhnik
Date:
Subject: Re: [Proposal] Global temporary tables