Skip site navigation (1) Skip section navigation (2)

Re: syntax error causes crafted data to be executed in shell

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Thomer M(dot) Gil" <postgresql(at)thomer(dot)com>,pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: syntax error causes crafted data to be executed in shell
Date: 2004-12-18 05:40:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

> 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

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2004-12-18 06:00:05
Subject: Re: solaris 10 with gcc 3.3.2
Previous:From: Tom LaneDate: 2004-12-18 05:00:43
Subject: Re: posgresql 8.0 RC1 missing schemas

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group