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-04 02:07:42
Message-ID: 23203.1393898862@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-04 02:16:47 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Andres Freund 2014-03-04 01:45:24 Re: ALTER TABLE lock strength reduction patch is unsafe