Re: Securing "make check" (CVE-2014-0067) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Securing "make check" (CVE-2014-0067)
Date
Msg-id 22183.1396293553@sss.pgh.pa.us
Whole thread Raw
In response to Re: Securing "make check" (CVE-2014-0067)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Securing "make check" (CVE-2014-0067)  (Christoph Berg <cb@df7cb.de>)
Re: Securing "make check" (CVE-2014-0067)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Mar 30, 2014 at 3:52 PM, Christoph Berg <cb@df7cb.de> wrote:
>> Oh, right. There's this other patch which apparently works so well
>> that I already forgot it's there:
>> 
>> Enable pg_regress --host=/path/to/socket:
>>
https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-9.4/trunk/view/head:/debian/patches/60-pg_regress_socketdir.patch

> Wasn't this patch submitted for inclusion in PostgreSQL at some point?
>  Did we have some good reason for not accepting it?

Well, other than very bad coding style (casual disregard of the message
localizability guidelines, and the dubious practice of two different
format strings in one printf call) it doesn't seem like a bad idea on
its face to allow pg_regress to set a socket path.  But do we want
pg_regress to *not* specify a listen_addresses string?  I think we
are currently setting that to empty intentionally on non-Windows.
If it defaults to not-empty, which is what I think will happen with
this patch, isn't that opening a different security hole?

I think we need a somewhat larger understanding of what cases we're trying
to support, in any case ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Cube extension kNN support
Next
From: Sergey Konoplev
Date:
Subject: Re: Cube extension kNN support