Re: Securing "make check" (CVE-2014-0067)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 22183.1396293553@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Securing "make check" (CVE-2014-0067)  (Christoph Berg <cb@df7cb.de>)
Re: Securing "make check" (CVE-2014-0067)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Cube extension kNN support
Следующее
От: Sergey Konoplev
Дата:
Сообщение: Re: Cube extension kNN support