On Sun, Sep 02, 2012 at 11:34:42PM -0400, Tom Lane wrote: > Heikki Linnakangas <hlinn...@iki.fi> writes: > > On 03.09.2012 03:23, Tom Lane wrote: > >> 1. As you can see above, the feature is triggered by specifying the new > >> connection option "standalone_datadir", whose value must be the location > >> of the data directory. I also invented an option "standalone_backend", > >> which can be set to specify which postgres executable to launch. > > > Are there security issues with this? If a user can specify libpq > > connection options, he can now execute any file he wants by passing it > > as standalone_backend. Granted, you shouldn't allow an untrusted user to > > specify libpq connection options, because allowing to open a TCP > > connection to an arbitrary address can be a problem by itself, but it > > seems like this might make the situation much worse. contrib/dblink > > springs to mind.. > > Hmm, that's a good point. Maybe we should only allow the executable > name to come from an environment variable? Seems kinda klugy though.
I don't think it's libpq's job to enforce security policy this way. In any event, it has no reason to presume an environment variable is a safer source. > >> 3. The bulk of the changes have to do with the fact that we need to keep > >> track of two file descriptors not one. > > > Would socketpair(2) be simpler? > > Hm, yes, but is it portable enough? It seems to be required by SUS v2, > so we're likely okay on the Unix side, but does Windows have this? Windows does not have socketpair(), nor a strict pipe() equivalent. I expect switching to socketpair() makes the Windows side trickier in some ways and simpler in others. +1 for exploring that direction first. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
