Pavel Stehule <pavel.steh...@gmail.com> writes:
> st 30. 1. 2019 18:51 odesÃlatel Bruce Momjian <br...@momjian.us> napsal:
>> I am wondering if we should just disallow CSV from STDIN, on security
>> grounds. How big a problem would that be for people? Would we have to
>> disable to STDOUT as well since it could not be restored? Should we
>> issue some kind of security warning in such cases? Should we document
>> this?
> it is pretty common pattern for etl, copy from stdin. I am thinking it can
> be big problem
Given how long we've had COPY CSV support, and the tiny number of
complaints to date, I do not think it's something to panic over.
Disallowing the functionality altogether is surely an overreaction.
I don't really see an argument for calling it a security problem,
given that pg_dump doesn't use CSV and it isn't the default for
anything else either. Sure, you can imagine some bad actor hoping
to cause problems by putting crafted data into a table, but how
does that data end up in a script that's using COPY CSV FROM STDIN
(as opposed to copying out-of-line data)? It's a bit far-fetched.
A documentation warning might be the appropriate response. I don't
see any plausible way for psql to actually fix the problem, short
of a protocol change to allow the backend to tell it how the data
stream is going to be parsed.
regards, tom lane
