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

Re: Tom Lane 2014-03-31 <22183(dot)1396293553(at)sss(dot)pgh(dot)pa(dot)us>
> >> 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

I had posted it here before, but I've got around to formally put it
into a CF, so sorry for not cleaning up. The double-formatstr thing
was done to avoid the need for twice as much almost-identical
formatstrs. There's probably smarter ways to do that.

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

The patch tries to reuse the existing switches; --host=/tmp is just
the equivalent of the "host=/tmp" connection parameter. Of course it
could as well introduce a new parameter --socket-dir=/tmp.

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

The patch solves a usability problem, security wasn't a concern at the
time of writing. I'll rethink that bit and come up with a better
solution.

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