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 17384.1346645480@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Noah Misch <noah@leadboat.com>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Sun, Sep 02, 2012 at 11:34:42PM -0400, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>>> 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.

>> 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.

One easy thing we could do that would at least narrow the risks is to
only allow the executable's *directory* to be specified, hardwiring the
executable file name to "postgres" (or "postgres.exe" I guess).

I'm inclined to think though that environment variables *are* more
secure in this context.  In the contrib/dblink example, such a
restriction would certainly help a lot.  In any case, we should at
least think of a way that an app using libpq can prevent this type
of attack short of parsing the conn string for itself.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Tom Lane
Date:
Subject: Re: pg_upgrade test mods for Windows/Mingw