From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: libpq should not look up all host addresses at once
In-reply-to: <20180809164208.3rsglmzjrg6rnudt@alvherre.pgsql>
References: <20180809164208.3rsglmzjrg6rnudt@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 09 Aug 2018 12:42:08 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10599.1533834500.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 Aug 2018 13:08:20 -0400
Message-ID: <10600.1533834500@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Aug-09, Tom Lane wrote:
>> Whilst fooling with the patch for CVE-2018-10915, I got annoyed by
>> the fact that connectDBStart() does the DNS lookups for all supplied
>> hostnames at once, and fails if any of them are bad.  It was reasonable
>> to do the lookup there when we only allowed one hostname, but now that
>> "host" can be a list, this is really pretty stupid.

> I'm not very familiar with the libpq code structure, but I think
> connectDBStart() is not used for synchronous connections, only
> asynchronous, is that correct?

No, it's used for all connections.  It's trivial to demonstrate the
problem in, eg, psql:

$ psql "host=3Dlocalhost"
[ connects OK ]
$ psql "host=3Dlocalhost,bogus"
psql: could not translate host name "bogus" to address: Name or service no=
t known

>> I'm tempted to call this a back-patchable bug fix, because the existing
>> behavior basically negates the entire value of the multi-hostname featu=
re
>> once you consider the possibility of DNS server failures.  But given th=
e
>> lack of field complaints, maybe that's an overreaction.

> Well, since it's broken, then I don't think it serves anybody very well.
> I vote to backpatch it to 10.

The only reason not to is that it involves a change in the contents of
struct PGconn.  But I suppose we could put the added fields at the end
in v10, if we're worried about clients looking into that struct (not
that they should be, but ...)

			regards, tom lane