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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: hlinnaka(at)iki(dot)fi
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-09-03 03:34:42
Message-ID: 16610.1346643282@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-09-03 03:47:06 Re: Yet another failure mode in pg_upgrade
Previous Message Andrew Dunstan 2012-09-03 03:29:48 pg_upgrade test mods for Windows/Mingw