On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm pretty much persuaded by Andres' point that we should not allow a
> child process to be launched under a client app without clear permission
> from the code of the app (and *not* just some environment variable that
> might have been set far away, perhaps by someone who doesn't know what the
> app assumes about SIGCHLD etc). So a separate connection call seems like
> not a bad idea. In the case of psql and pg_dump it'd be reasonable to
> invent a separate command line switch that drives use of this call instead
> of normal PQconnect. Doing that, and *not* allowing the text of the
> connection string to determine it, seems like it pretty well solves any
> security objections.
Yep.
> It might be unpleasant to use in some cases, though.
Why would there be more than a few cases in the first place? Who is
going to use this beyond psql, pg_dump(all), and pg_upgrade, and why?
> Another issue is that we have too many variants of PQconnect already;
> which of them are we prepared to clone for this hypothetical new
> connection method?
PQconnectdbParams, I assume. Isn't that the one to rule them all,
modulo async connect which I can't think is relevant here?
Or don't clone that one but instead have
PQnextConnectionShouldForkThisBinary('...') and let the psql/pg_dump
switch be --standalone=full-path-to-the-postgres-binary.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company