From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | hlinnaka(at)iki(dot)fi, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proof of concept: standalone backend with full FE/BE protocol |
Date: | 2012-09-03 04:11:20 |
Message-ID: | 17384.1346645480@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Sun, Sep 02, 2012 at 11:34:42PM -0400, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka(at)iki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-03 04:19:51 | Re: pg_upgrade test mods for Windows/Mingw |
Previous Message | Noah Misch | 2012-09-03 04:02:42 | Re: Proof of concept: standalone backend with full FE/BE protocol |