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

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 20140330014531.GE170273@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Christoph Berg <cb@df7cb.de>)
Ответы Re: Securing "make check" (CVE-2014-0067)  (Christoph Berg <cb@df7cb.de>)
Список pgsql-hackers
On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote:
> Fwiw, to relocate the pg_regress socket dir, there is already the
> possibility to run make check EXTRA_REGRESS_OPTS="--host=/tmp". (With
> the pending fix I sent yesterday to extend this to contrib/test_decoding.)

That doesn't work for "make check", because the postmaster ends up with
"listen_addresses=/tmp".

> We've been putting a small patch into pg_upgrade in Debian to work
> around too long socket paths generated by pg_upgrade during running
> the testsuite (and effectively on end user systems, but I don't think
> anyone is using such long paths there).
> 
> A similar code bit could be put into pg_regress itself.

Thanks for reminding me about Debian's troubles here.  Once the dust settles
on pg_regress, it will probably make sense to do likewise to pg_upgrade.

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: [RFC] What should we do for reliable WAL archiving?
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Fwd: Proposal: variant of regclass