Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 16610.1346643282@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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.

>> 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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: pg_upgrade test mods for Windows/Mingw
Next
From: Tom Lane
Date:
Subject: Re: Yet another failure mode in pg_upgrade