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

Re: BUG #2424: initdb Did Not Escape the Password

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: imacat <imacat(at)mail(dot)imacat(dot)idv(dot)tw>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #2424: initdb Did Not Escape the Password
Date: 2006-05-27 16:16:26
Message-ID: 23763.1148746586@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:

I don't particularly like this patch, because it is predicated on a
false assumption, namely that initdb uses libpq to talk to the backend.
ISTM PQescapeString is not the thing to use.  (As a concrete example
of why not, there'll be no way to make it use the correct value of
standard_conforming_strings, when that default changes.)

I think the best solution is probably to use the existing escape_quotes
function and to place its output in an E'' string.

I looked through initdb to see if there were any other places where it
was creating SQL string literals that might have escaping problems.
All of the COPY commands it issues are potentially at risk: consider
the possibility that the installation sharedir has a quote or backslash
in its path.  I didn't see any other holes though.

Will fix this later today.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Volkan YAZICIDate: 2006-05-27 16:16:27
Subject: Re: Strange random() Correlation
Previous:From: Tom LaneDate: 2006-05-27 15:50:33
Subject: Re: Strange random() Correlation

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