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
|
Список | 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 по дате отправления: