Re: eval function

From: Sim Zacks
Subject: Re: eval function
Date: ,
Msg-id: 4E34DF18.9000300@compulab.co.il
(view: Whole thread, Raw)
In response to: Re: eval function  (Chris Travers)
Responses: Re: eval function  (Chris Travers)
List: pgsql-general

Tree view

eval function  (Sim Zacks, )
 Re: eval function  (Merlin Moncure, )
  Re: eval function  (Tom Lane, )
   Re: eval function  ("David Johnston", )
    Re: eval function  (Merlin Moncure, )
     Re: eval function  (Chris Travers, )
      Re: eval function  (Merlin Moncure, )
    Re: eval function  (Chris Travers, )
     Re: eval function  (Sim Zacks, )
      Re: eval function  (Chris Travers, )
       Re: eval function  (Sim Zacks, )
        Re: eval function  (Chris Travers, )
         Re: eval function  (saeed ahmed, )
          Re: eval function  (John R Pierce, )
          User Interface [was : eval function]  (Vincent Veyron, )
   Re: eval function  (Sim Zacks, )
    Re: eval function  (Jaime Casanova, )
     Re: eval function  (Sim Zacks, )
 Re: eval function  (Chris Travers, )

On 07/28/2011 06:28 PM, Chris Travers wrote:

> On Thu, Jul 28, 2011 at 8:08 AM, David Johnston<>  wrote:
>
>> 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?
> I don't think the hole can be plugged.  The point of the function is
> to execute arbitrary sql code.  That means doing SQL injection
> purposely in the function.  I don't think there is a way around it
> because SQL injection is specifically what is desired,
>
> Best Wishes,
> Chris Travers
On one hand the hole can't be plugged because as you mentioned that is
the point of the function. On the other hand, if the function is not
being run as security definer, the account running it would need to have
the rights to do whatever he is injecting. If "1); delete..." would
work, then the user could just as easily do Delete... without using the
function.

The only problem that I see (correct me if I'm wrong) is anonymous
injection through a user that has rights that we wouldn't want the
actual user to have, which is not recommended in any case.

Sim



pgsql-general by date:

From: Alban Hertroys
Date:
Subject: Re: Finding referecing and referenced tables, adaptation from David Fetter's solution
From: Chris Travers
Date:
Subject: Re: eval function