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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Securing "make check" (CVE-2014-0067)
Date: 2014-03-02 18:27:18
Message-ID: 1492.1393784838@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> One option that would simplify things is to fix only non-Windows in the back
> branches, via socket protection, and fix Windows in HEAD only. We could even
> do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes.

+1 for that solution, if it's not an unreasonable amount of work to add
named-pipe sockets in Windows. That would offer a feature to Windows
users that they didn't have before, ie the ability to restrict connections
based on filesystem permissions; so it seems useful quite aside from any
"make check" considerations.

There's an independent question of whether the regression tests will work
for "make installcheck" against a server that's not set up for trust auth.
I'm inclined to think that we can leave it to the user to generate
appropriate passwords if he's using password auth, but don't we still
need some test procedure adjustments?

Also, to what extent does any of this affect buildfarm animals? Whatever
we do for "make check" will presumably make those tests safe for them,
but how are the postmasters they test under "make installcheck" set up?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message james 2014-03-02 18:54:06 Re: Securing "make check" (CVE-2014-0067)
Previous Message Stephen Frost 2014-03-02 17:23:22 Re: Securing "make check" (CVE-2014-0067)