Noah Misch <n...@leadboat.com> writes: > On Mon, Sep 03, 2012 at 12:11:20AM -0400, Tom Lane wrote: >> 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).
> If the user has any interactive access to the machine, he could make a > /tmp/X/postgres symbolic link to the program of his choosing. I said "narrow", not "eliminate" ;-) >> 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. > Trusting the environment over connection strings is a wrong policy for, say, a > setuid command-line program. Suppose such a program passes libpq a fixed > connection string to access its embedded database. The program will find > itself explicitly clearing this environment variable to regain safety. Well, a program that was concerned with this would *already* want to clear every environment variable that affects libpq, else its database connections could get redirected somewhere surprising. libpq already provides enough infrastructure to get the list of such variables ... but only ones that are associated with connection string parameters. So for this purpose, making the standalone-control parameters not be accessible through connection strings would actually be worse. >> 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. > My recommendation to affected application authors is to pass the connection > string through PQconninfoParse(). Walk the array, validating or rejecting > arguments like "host" and "standalone_datadir". For maximum safety, the > application would need to reject any unanticipated parameters. We might > soften that by adding a "bool critical" field to PQconninfoOption that > documents whether the option must be understood by a program validating a > connection. Compare the idea of the PNG chunk header's "ancillary" bit. > Parameters like "host" and "standalone_datadir" would be critical, while > "application_name" and "connect_timeout" would be ancillary. But this is a > tough line to draw rigorously. Even more to the point, we can't seriously expect application authors to know what to do with connection parameters that didn't exist when they were writing their code. Every new security-critical parameter would represent a new set of bugs. I'm reluctantly coming to the conclusion that we can't pass these parameters through the regular libpq connection string mechanism, and will have to invent something else. That's awfully nasty though; it will pretty much cripple the idea that this would be a simple way to invoke a quasi-embedded variant of Postgres. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers