Re: Proof of concept: standalone backend with full FE/BE protocol

On Sun, Sep 02, 2012 at 11:34:42PM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@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.