Re: Securing "make check" (CVE-2014-0067)
От
Noah Misch
Тема
Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id
20140608135713.GA525142@tornado.leadboat.com
Ответ на
Re: Securing "make check" (CVE-2014-0067) (Noah Misch)
Список
Дерево обсуждения
Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Alvaro Herrera <alvherre@2ndquadrant.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Bruce Momjian <bruce@momjian.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) yamt@netbsd.org (YAMAMOTO Takashi)
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) yamt@netbsd.org (YAMAMOTO Takashi)
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Robert Haas <robertmhaas@gmail.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Robert Haas <robertmhaas@gmail.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Bruce Momjian <bruce@momjian.us>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Christoph Berg <cb@df7cb.de>
Re: Securing "make check" (CVE-2014-0067) Stephen Frost <sfrost@snowman.net>
Re: Securing "make check" (CVE-2014-0067) Andrew Dunstan <andrew@dunslane.net>
Re: Securing "make check" (CVE-2014-0067) Magnus Hagander <magnus@hagander.net>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Andrew Dunstan <andrew@dunslane.net>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Stephen Frost <sfrost@snowman.net>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Tom Lane <tgl@sss.pgh.pa.us>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Andrew Dunstan <andrew@dunslane.net>
Re: Securing "make check" (CVE-2014-0067) Magnus Hagander <magnus@hagander.net>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) David Rowley <dgrowleyml@gmail.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) David Rowley <dgrowleyml@gmail.com>
Re: Securing "make check" (CVE-2014-0067) Noah Misch <noah@leadboat.com>
hamerkop is stuck Noah Misch <noah@leadboat.com>
Re: hamerkop is stuck TAKATSUKA Haruka <harukat@sraoss.co.jp>
Re: hamerkop is stuck Noah Misch <noah@leadboat.com>
Re: Securing "make check" (CVE-2014-0067) Michael Paquier <michael.paquier@gmail.com>
Re: Securing "make check" (CVE-2014-0067) Magnus Hagander <magnus@hagander.net>
Re: Securing "make check" (CVE-2014-0067) james <james@mansionfamily.plus.com>
Re: Securing "make check" (CVE-2014-0067) Stephen Frost <sfrost@snowman.net>
Re: Securing "make check" (CVE-2014-0067) Dave Page <dpage@pgadmin.org>
Re: Securing "make check" (CVE-2014-0067) Stephen Frost <sfrost@snowman.net>
On Sun, Mar 23, 2014 at 07:04:20PM -0400, Noah Misch wrote: > On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote: > > On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote: > > > I'm inclined to suggest that we should put the socket under $CWD by > > > default, but provide some way for the user to override that choice. > > > If they want to put it in /tmp, it's on their head as to how secure > > > that is. On most modern platforms it'd be fine. > > > > I am skeptical about the value of protecting systems with non-sticky /tmp, but > > long $CWD isn't of great importance, either. I'm fine with your suggestion. > > Though the $CWD or one of its parents could be world-writable, that would > > typically mean an attacker could just replace the test cases directly. > > Here's the patch. The temporary data directory makes for a convenient socket > directory; initdb already gives it mode 0700, and we have existing > arrangements to purge it when finished. One can override the socket directory > by defining PG_REGRESS_SOCK_DIR in the environment. Socket path length limitations thwarted that patch: http://www.postgresql.org/message-id/flat/E1WTnV2-00047S-NM@gemulon.postgresql.org Here's an update that places the socket in a temporary subdirectory of /tmp. The first attached patch adds NetBSD mkdtemp() to libpgport. The second, principal, patch uses mkdtemp() to implement this design in pg_regress. The corresponding change to contrib/pg_upgrade/test.sh is based on the "configure" script's arrangements for its temporary directory. NetBSD's mkdtemp() has assertions, and I initially mapped its assertion macro to our Assert(). However, a bug in our MinGW build process causes build failures if an Assert() call appears in libpgport. I will post about that in a new thread. The affected assertions were uncompelling, so I dropped them. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления