Itagaki Takahiro <itagaki.takahiro@gmail.com> writes:
> On Tue, Dec 14, 2010 at 10:53, Robert Haas <robertmhaas@gmail.com> wrote:
>> I'm looking at this patch and I'm confused. Why do we need this at
>> all? pg_read_binary_file() seems like it might be useful to somebody,
>> but I don't see what it has to do with extensions. And the rest of
>> this doesn't appear to provide any new functionality. The extension
>> mechanism hardly needs SQL-callable functions.
> Hmm, I've expected that the EXTENSION patch would use the SQL functions
> like as SPI_exec("SELECT pg_execute_sql(pg_read_file($1))", ...), but
> it actually uses internal functions and nested DirectFunctionCalls.
> So, the most important part of this patch is allowing to read any
> files in the server file system. The current pg_read_file() allows
> to read only files under $PGDATA and pg_log.
Has anyone thought twice about the security implications of that?
Not to mention that in most cases, the very last thing we want is to
have to specify an exact full path?
I think we'd be better off insisting that the extension files be under
sharedir or some such place.
In any case, I concur with what I gather Robert is thinking, which is
that there is no good reason to be exposing any of this at the SQL level.
regards, tom lane