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

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(at)gmx(dot)net http://funkturm.homeip.net/~peter