Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yes, it's not a trivial fix either. We'll have to provide functions or
>> views that replace the current usages without letting the user insert
>> untrusted strings.
> Maybe I'm all wet here, but don't we need to come up with something we
> can back-patch?
Well, ideally yes, but if it's not actually *secure* then there's no
point --- and I don't believe that the approach of making readfuncs.c
secure against malicious input has the proverbial snowball's chance
of ever being bulletproof.
[ thinks for awhile... ] I wonder whether there is any way of locking
down pg_get_expr so that it throws an error if called with anything
except a suitable field from one of the system catalogs. There are only
a few usage patterns that we need to allow, no? At least in recent PG
versions it is possible for the function to check that its input
expression is a Var. If we had some (probably horridly ugly) way to
obtain the rangetable entry the Var refers to, we could put code into
pg_get_expr to barf if it's not used in a context like
"select pg_get_expr(adbin) from pg_attrdef".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
