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

Re: Noah Misch 2014-03-30 <20140330014531(dot)GE170273(at)tornado(dot)leadboat(dot)com>
> 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".

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

This, along with 61-extra_regress_opts and 64-pg_upgrade-sockdir (at
the same location, both also recently posted here) should be safe for
general use, i.e. inclusion in git. (I didn't check how much this
overlaps with what Noah tried, I'm just mentioning the patches here
because they work for Debian.)

There's two other patches: 62-pg_upgrade-test-in-tmp hardcodes /tmp
for the pg_upgrade test which should obviously be done smarter, and
63-pg_upgrade-test-bindir which forwards PSQLDIR through
contrib/pg_upgrade/test.sh. The latter is probably also safe for
general use, but I'd be more confident if someone rechecked that.

> > 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.

Nod, it'd be nice if we could get rid of some patches in Debian.

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/