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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: hlinnaka@iki.fi
Cc: pgsql-hackers@postgresql.org
Date: 2012-09-03T03:34:42Z
Lists: 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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove now redundant pgpipe code.