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

From Tom Lane
Subject Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Date
Msg-id 9316.992061081@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  ("Joe Conway" <joe@conway-family.com>)
Responses Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
"Joe Conway" <joe@conway-family.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


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Strange behavior on multiple primary key behavior deleting childr en
Next
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: ERROR: Memory exhausted in AllocSetAlloc(909324558)