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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Дата
Msg-id Pine.LNX.4.30.0106011651210.757-100000@peter.localdomain
обсуждение исходный текст
Ответ на Fw: Isn't pg_statistic a security hole - Solution Proposal  ("Joe Conway" <joe@conway-family.com>)
Ответы Re: Fw: Isn't pg_statistic a security hole - Solution Proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
Joe Conway writes:

> The patch applies cleanly against cvs tip. One item I was not sure about was
> the selection of the OID value for the new function. I chose 1920 for no
> other reason that the highest OID in pg_proc.h was 1909, and this seemed
> like a safe value. Is there somewhere I should have looked for guidance on
> this?

~/pgsql/src/include/catalog$ ./unused_oids
3 - 11
90
143
352 - 353
1264
1713 - 1717
1813
1910 - 16383


> > ANSI SQL 92 does not have any functions defined for retrieving privilege
> > information. It does, however define an "information schema" and
> "definition
> > schema" which among other things includes a TABLE_PRIVILEGES view.

Yes, that's what we pretty much want to do once we have schema support.
The function you propose, or one similar to it, will probably be needed to
make this work.

> >   select has_privilege('postgres', 'pg_shadow', 'select');
> >
> > where
> >   the first parameter is any valid user name
> >   the second parameter can be a table, view, or sequence
> >   the third parameter  can be 'select', 'insert', 'update', 'delete', or
> > 'rule'

This is probably going to blow up when we have the said schema support.
Probably better to reference things by oid.  Also, since things other than
relations might have privileges sometime, the function name should
probably imply this; maybe "has_table_privilege".

Implementation notes:

* This function should probably go into backend/utils/adt/acl.c.

* You don't need PG_FUNCTION_INFO_V1 for built-in functions.

* I'm not sure whether it's useful to handle NULL parameters explicitly.
  The common approach is to return NULL, which would be semantically right
  for this function.

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


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

Предыдущее
От: "Joe Conway"
Дата:
Сообщение: Fw: Isn't pg_statistic a security hole - Solution Proposal
Следующее
От: Ian Lance Taylor
Дата:
Сообщение: Re: AW: [HACKERS] Re: Support for %TYPE in CREATE FUNCTION