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

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Дата
Msg-id 006301c0f083$77eda960$d7d310ac@jecw2k1
обсуждение исходный текст
Ответ на Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > ISTM the name-based variants will primarily be used for user-entered
> > names, and in that case the user can reasonably expect that a name
> > will be interpreted the same way as if he'd written it out in a query.
>
> That would be correct if the user were actually entering the name in the
> same way, i.e., unquoted or double-quoted.
>
> > The nextval approach is ugly, I'll grant you, but it's also functional.
>
> But it's incompatible with the SQL conventions.
>

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
QuotedRelname", 'insert');
 

instead of
  select has_table_privilege(current_user, 'pg_class', 'insert');    or  select has_table_privilege(current_user, '"My
QuotedRelname"',
 
'insert');

?

If so, what would be involved in fixing it?

From an end user's perspective, I wouldn't mind the latter syntax, although
the former is clearly more intuitive. But I'd rather have the second form
than nothing (just MHO).

-- Joe




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)
Следующее
От: Mike Cianflone
Дата:
Сообщение: Strange behavior on multiple primary key behavior deleting childr en