On Tue, Sep 6, 2016 at 9:43 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 8/11/16 9:12 PM, Michael Paquier wrote: >> Note that pg_dump[all] and pg_upgrade already have safeguards against >> those things per the same routines putting quotes for execution as >> commands into psql and shell. So attached is a patch to implement this >> restriction in the backend, and I am adding that to the next CF for >> 10.0. Attached is as well a script able to trigger those errors. > > After further review, I have my doubts about this approach. > > Everything that is using appendShellString() is now going to reject LF > and CR characters, but there is no systematic way by which this is > managed, enforced, or documented. It happens that right now most of the > affected cases are user and database names, but there are others. For > example, you cannot anymore install PostgreSQL into a path containing > LF/CR, because initdb will fail when it composes the pg_ctl command line > to print out. Also, initdb will fail if the data directory name > contains LF/CR, but it creates the directory nonetheless. (Apparently, > it doesn't even clean it up.) But for example pg_ctl and pg_basebackup > and postgres itself handle all of that just fine. This is a slowly > growing mess. > > I think the way forward here, if any, is to work on removing these > restrictions, not to keep sprinkling them around.
If we were talking about pathnames containing spaces, I would agree, but I've never heard of a legitimate pathname containing CR or LF. I can't see us losing much by refusing to allow such pathnames, except for security holes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers