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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: yamt(at)netbsd(dot)org (YAMAMOTO Takashi)
Cc: noah(at)leadboat(dot)com, bruce(at)momjian(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Securing "make check" (CVE-2014-0067)
Date: 2014-04-04 13:50:14
Message-ID: 5238.1396619414@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

yamt(at)netbsd(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-04 13:56:38 Re: Allocations in critical section (was Re: WAL format and API changes (9.5))
Previous Message Andres Freund 2014-04-04 13:41:24 Re: ipc_test