On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Yeah. If we're going to do this at all, and I'm not convinced it's
>> worth the work, I think it's definitely good to support a variant
>> where we specify exactly the things that will be passed to exec().
>> There's just too many ways to accidentally shoot yourself in the foot
>> otherwise. If we want to have an option that lets people shoot
>> themselves in the foot, that's fine. But I think we'd be smart not to
>> make that the only option.
>
> [ shrug... ] Once again, that will turn this from a ten-line patch
> into hundreds of lines (and some more, different, hundreds of lines
> for Windows I bet), with a corresponding growth in the opportunities
> for bugs, for a benefit that's at best debatable.
>
> 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.
I just don't agree with that. popen() is to security holes as cars
are to alcohol-related fatalities. In each case, the first one
doesn't directly cause the second one; but it's a pretty darn powerful
enabler. Your proposed solution won't force people to write insecure
applications; it'll just make it much more likely that they will do so
... after which, presumably, you'll tell them it's their own darn
fault for using the attractive nuisance. The list of security
vulnerabilities that are the result of insufficiently careful
validation of strings passed to popen() is extremely long. 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
