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

"Joe Conway" <joe(at)conway-family(dot)com> writes:
> 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 Quoted Relname", 'insert');

It'd be really nice to do that, but I don't see any reasonable way to do
it. The problem is that the unquoted relation name will probably be
resolved (to the wrong thing) before we discover that the function wants
it to be resolved as a relation OID. Remember that the arguments of a
function have to be resolved before we can even start to look up the
function, since function lookup depends on the types of the arguments.

I have just thought of a possible compromise. Peter is right that we
don't want case conversion on table names that are extracted from
catalogs. But I think we do want it on table names expressed as string
literals. Could we make the assumption that table names in catalogs
will be of type 'name'? If so, it'd work to make two versions of the
has_table_privilege function, one taking type "name" and the other
taking type "text". The "name" version would take its input as-is,
the "text" version would do case folding and truncation. This would
work transparently for queries selecting relation names from the system
catalogs, and it'd also work transparently for queries using unmarked
string literals (which will be preferentially resolved as type "text").
Worst case if the system makes the wrong choice is you throw in an
explicit coercion to name or text. Comments?

regards, tom lane