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
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 |