Re: backslash-dot quoting in COPY CSV

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: backslash-dot quoting in COPY CSV
Дата
Msg-id 26552.1548872459@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: backslash-dot quoting in COPY CSV  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: backslash-dot quoting in COPY CSV  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> st 30. 1. 2019 18:51 odesílatel Bruce Momjian <bruce@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: backslash-dot quoting in COPY CSV
Следующее
От: David Rowley
Дата:
Сообщение: Re: speeding up planning with partitions