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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 14724.1393728199@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: Custom Scan APIs (Re: Custom Plan node)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: commit fest status and release timeline