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.
