Skip site navigation (1) Skip section navigation (2)

Re: eval function

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: David Johnston <polobo(at)yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sim Zacks <sim(at)compulab(dot)co(dot)il>, PostgreSQL general <pgsql-general(at)postgresql(dot)org>
Subject: Re: eval function
Date: 2011-07-28 15:23:55
Message-ID: CAHyXU0wOUm=XxWtpocumJMF4gHKjk0kru4JW07cDUTFKoYqTJA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On Thu, Jul 28, 2011 at 10:08 AM, David Johnston <polobo(at)yahoo(dot)com> wrote:
>
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> Couple points:
>> *) why a special case for boolean values?
>
> That seemed weird to me too ...
>
>> *) this should be immutable
>
> What if the passed expression is volatile?  Better to be safe.
>
> ---------------------------------
>
> At best, based upon the example using "current_timestamp()", you could only
> mark it as being stable, right?
>
> Also not mentioned; what risk is there of this function being hacked?  It
> places the supplied data within a "SELECT  (....) AS column_alias" structure
> so it seems to be pretty safe but can you devise a string that would, say,
> delete data or something similar.  I would expect the following: '1); DELETE
> FROM table; SELECT (2' to be dangerous.  What functions would you use to
> make the input string safe?  Does "quote_literal()" plug this hole?

This function is an absolute no-go if the string literal is coming
from untrusted source, and any robust defenses would ruin the intended
effect of the function.  There are a number of nasty ways you can (at
minimum) DOS your database by allowing arbitrary sql.  For example,
using generate_series() and advisory_locks you can exhaust lock space.

merlin

In response to

Responses

pgsql-general by date

Next:From: Chris TraversDate: 2011-07-28 15:28:17
Subject: Re: eval function
Previous:From: David JohnstonDate: 2011-07-28 15:08:32
Subject: Re: eval function

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group