On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers