On 11/14/13, 1:41 AM, Amit Kapila wrote: > Security Concern > ----------------------------- > If a user can specify libpq connection options, he can now execute > any file he wants by passing it as standalone_backend. > > Method to resolve Security concern > -------------------------------------------------------- > If an application wants to allow these connection parameters to be > used, it would need to do PQenableStartServer() first. If it doesn't, > those connection parameters will be rejected.
I don't think this really helps. You can't tell with reasonable effort or certainty whether a given program is calling PQenableStartServer(), so you cannot audit this from the outside. Also, someone could, depending on circumstances, dynamically load a module that calls PQenableStartServer(), thus circumventing this check. And maybe before long someone will patch up all drivers to call PQenableStartServer() automatically, because why shouldn't I be able to run a standalone backend from PHP or Ruby? Also, at some point at least, something like phpPgAdmin called pg_dump internally, so you could imagine that in situations like that, assuming that pg_dump called PQenableStartServer(), with a little bit craftiness, you could expose the execute-any-file hole through a web server. I don't have a better idea right now how to set up these connection parameters in a way that you can only set them in certain "safe" circumstances. I would consider sidestepping this entire issue by having the stand-alone backend create a Unix-domain socket and have a client connect to that in the normal way. At least if you split the patch that way, you might alleviate some concerns of others about whether this patch is about fixing standalone mode vs. allowing using standalone mode with psql vs. making a fully embedded database. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers