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 14724.1393728199@sss.pgh.pa.us
Whole thread Raw
In response to Re: Securing "make check" (CVE-2014-0067)  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 03/01/2014 05:10 PM, Tom Lane wrote:
>> BTW, a different problem with the proposed patch is that it changes
>> some test cases in ecpg and contrib/dblink, apparently to avoid session
>> reconnections.  That seems likely to me to be losing test coverage.
>> Perhaps there is no alternative, but I'd like to have some discussion
>> around that point as well.

> Yeah. Assuming we make the changes you're suggesting that should no 
> longer be necessary, right?

Not sure.  I believe the point of those changes is that the scaffolding
only sets up a password for the original superuser, so that connecting
as anybody else will fail if the test postmaster is configured for
password auth.  If so, the only way to avoid doing any work would be
if we don't implement any fix at all for Windows.

Whether or not you're worried about the security of "make check" on
Windows, there are definitely some things to be unhappy about here.
One being that the core regression tests are evidently not testing
connecting as anybody but superuser; and the proposed changes would remove
such testing from contrib and ecpg as well, which is surely not better
from a coverage standpoint.  (It's not terribly hard to imagine
permissions bugs that would cause postinit.c to fail for non-superusers.)

Another issue is that (I presume, haven't checked) "make installcheck"
on contrib or ecpg will currently fail against a server that's not
configured for trust auth.  Ideally you should be able to do "make
installcheck" against a reasonably-configured server.

I'm not real sure what to do about either of those points, but I am sure
that the proposed patch isn't moving the ball downfield.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)
Next
From: Michael Paquier
Date:
Subject: Re: commit fest status and release timeline