Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The biggest problem this patch has had from the very beginning is
>> overdesign, and this is more of the same. Let's please just define the
>> feature as "popen, not fopen, the given string" and have done.
> ... If we give
> people a feature that can only be leveraged via popen(), the chances
> that someone will thereby open a security hole are indistinguishable
> from 1.
You are absolutely right that this feature is a security risk, but it
will be one whether it exposes popen() or only exec(). I do not believe
that the incremental gain in security from disallowing shell notation
is worth either the loss of functionality or the amount of added effort
(and added bugs, some of which will be security issues in themselves)
we'd need to write it that way.
The correct response to the security risks is to (a) make it
superuser-only and (b) document that it's a seriously bad idea to allow
the argument string to come from any untrusted sources. Please note
that we'd have to do these same things with an exec-based patch.
regards, tom lane
