Noah Misch <n...@leadboat.com> writes: > On Sun, Sep 02, 2012 at 11:34:42PM -0400, Tom Lane wrote: >> Heikki Linnakangas <hlinn...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers