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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: yamt@netbsd.org (YAMAMOTO Takashi)
Cc: noah@leadboat.com, bruce@momjian.us, pgsql-hackers@postgresql.org
Date: 2014-04-04T13:50:14Z
Lists: pgsql-hackers
yamt@netbsd.org (YAMAMOTO Takashi) writes:
>> On Fri, Apr 04, 2014 at 02:36:05AM +0000, YAMAMOTO Takashi wrote:
>>> openvswitch has some tricks to overcome the socket path length
>>> limitation using symlink.  (or procfs where available)
>>> iirc these were introduced for debian builds which use deep CWD.

>> That's another reasonable approach.  Does it have a notable advantage over
>> placing the socket in a subdirectory of /tmp?  Offhand, the security and
>> compatibility consequences look similar.

> an advantage is that the socket can be placed under CWD
> and thus automatically obeys its directory permissions etc.

I'm confused.  The proposed alternative is to make a symlink in /tmp
or someplace like that, pointing to a socket that might be deeply buried?
How is that any better from a security standpoint from putting the socket
right in /tmp?  If /tmp is not sticky then an attacker can replace the
symlink, no?

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Have config_sspi_auth() permit IPv6 localhost connections.

  2. Lock down regression testing temporary clusters on Windows.

  3. Use a separate temporary directory for the Unix-domain socket

  4. Secure Unix-domain sockets of "make check" temporary clusters.