Re: Recognizing superuser in pg_hba.conf

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Recognizing superuser in pg_hba.conf
Дата
Msg-id 5526.1578582366@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Recognizing superuser in pg_hba.conf  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Recognizing superuser in pg_hba.conf  (Stephen Frost <sfrost@snowman.net>)
Re: Recognizing superuser in pg_hba.conf  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [Proposal] Global temporary tables