Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
От | Joe Conway |
---|---|
Тема | Re: Fw: Isn't pg_statistic a security hole - Solution Proposal |
Дата | |
Msg-id | 00a101c0eaea$e2a67320$dad410ac@jecw2k1 обсуждение исходный текст |
Ответ на | Re: Fw: Isn't pg_statistic a security hole - Solution Proposal (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-patches |
> The standard approach for C-coded functions is to mark them > 'proisstrict' in pg_proc, and then not waste any code checking for NULL; > the function manager takes care of it for you. The only reason not to > do it that way is if you actually want to return non-NULL for (some > cases with) NULL inputs. Offhand this looks like a strict function to > me... > Thanks for the feedback! To summarize the recommended changes: - put function into backend/utils/adt/acl.c. - remove PG_FUNCTION_INFO_V1 - mark 'proisstrict' in pg_proc - rename to has_table_privilege() - overload the function name for 6 versions (OIDs 1920 - 1925): -> has_table_privilege(text username, text relname, text priv) -> has_table_privilege(oid usesysid, text relname, text priv) -> has_table_privilege(oid usesysid, oid reloid, text priv) -> has_table_privilege(text username, oid reloid, text priv) -> has_table_privilege(text relname, text priv) /* assumes current_user */ -> has_table_privilege(oid reloid, text priv) /* assumes current_user */ New patch forthcoming . . . -- Joe
В списке pgsql-patches по дате отправления: