Re: syntax error causes crafted data to be executed in shell
От | Tom Lane |
---|---|
Тема | Re: syntax error causes crafted data to be executed in shell |
Дата | |
Msg-id | 28174.1103348415@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: syntax error causes crafted data to be executed in shell (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-bugs |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > So if a backslash command fails we discard the rest of the line? Well, the point is that right now we *don't*. But I'm thinking we should. > How did user data ever get to psql in this way? As I understand the scenario, it's that a 7.3-or-later pg_dump could produce COPY foo(a, b, c) FROM stdin; col1 \N `touch gotcha` \. If you tried to load this dump file into a pre-7.3 server then the server would barf on the COPY column list, which we didn't have pre-7.3, and so it would not send the protocol command to psql to switch into COPY IN mode. Therefore psql would read the next line as normal input and would think that \N was a backslash command and `touch gotcha` was a backticked argument to same. (Thomer was waving his hands about "missing FROM" but I think that's a thoroughly garbled report of the issue, because AFAIR no version of pg_dump has ever emitted COPY commands without a "FROM stdin" clause.) What this says to me is that we should be really, really cautious about changing the format of the COPY commands emitted by pg_dump ever again. For safety's sake they've got to be both forward and backward compatible. regards, tom lane
В списке pgsql-bugs по дате отправления: