Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Дата
Msg-id 9316.992061081@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  ("Joe Conway" <joe@conway-family.com>)
Ответы Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
"Joe Conway" <joe@conway-family.com> writes:
> Is the concern that the name-based variants of the function should be called
> like:

>    select has_table_privilege(current_user, pg_class, 'insert');
>      or
>    select has_table_privilege(current_user, "My Quoted Relname", 'insert');

It'd be really nice to do that, but I don't see any reasonable way to do
it.  The problem is that the unquoted relation name will probably be
resolved (to the wrong thing) before we discover that the function wants
it to be resolved as a relation OID.  Remember that the arguments of a
function have to be resolved before we can even start to look up the
function, since function lookup depends on the types of the arguments.

I have just thought of a possible compromise.  Peter is right that we
don't want case conversion on table names that are extracted from
catalogs.  But I think we do want it on table names expressed as string
literals.  Could we make the assumption that table names in catalogs
will be of type 'name'?  If so, it'd work to make two versions of the 
has_table_privilege function, one taking type "name" and the other
taking type "text".  The "name" version would take its input as-is,
the "text" version would do case folding and truncation.  This would
work transparently for queries selecting relation names from the system
catalogs, and it'd also work transparently for queries using unmarked
string literals (which will be preferentially resolved as type "text").
Worst case if the system makes the wrong choice is you throw in an
explicit coercion to name or text.  Comments?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Strange behavior on multiple primary key behavior deleting childr en
Следующее
От: darcy@druid.net (D'Arcy J.M. Cain)
Дата:
Сообщение: Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)