Re: Securing "make check" (CVE-2014-0067) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Securing "make check" (CVE-2014-0067)
Date
Msg-id 1492.1393784838@sss.pgh.pa.us
Whole thread Raw
In response to Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
Responses Re: Securing "make check" (CVE-2014-0067)  (Andrew Dunstan <andrew@dunslane.net>)
Re: Securing "make check" (CVE-2014-0067)  (Magnus Hagander <magnus@hagander.net>)
Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Securing "make check" (CVE-2014-0067)
Next
From: james
Date:
Subject: Re: Securing "make check" (CVE-2014-0067)