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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 23203.1393898862@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I wrote:
> Placing the socket anywhere besides the default location will require
> setting PGHOST anyway, so I don't see that this argument holds much water.
> The cleanup aspect is likewise not that exciting; pg_regress creates a lot
> of stuff it doesn't remove.

There's another point here, if you think back to the discussion as it
stood before we noticed that there was a security problem.  What was
originally under discussion was making life easier for packagers who
want to build with a default socket location like /var/run/postgresql/.
In a build environment, that directory may not exist, and even if it
does, there is no way that the build user should have write permission
on it.  So it is already the case that some packagers have to override
the socket location if they want to do "make check" while packaging,
and what we were originally on about was making that part of the normal
pg_regress procedures instead of being something requiring patching.

So, whether or not unix_socket_permissions would be a bulletproof
security fix by itself, I'd still want to see some provisions made
for putting the socket into a local directory during "make check".
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe