Re: Securing "make check" (CVE-2014-0067) - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Securing "make check" (CVE-2014-0067)
Date
Msg-id 20140306035636.GB3527902@tornado.leadboat.com
Whole thread Raw
In response to Re: Securing "make check" (CVE-2014-0067)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Securing "make check" (CVE-2014-0067)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Securing "make check" (CVE-2014-0067)  (yamt@netbsd.org (YAMAMOTO Takashi))
List pgsql-hackers
On Tue, Mar 04, 2014 at 07:10:27PM -0500, Bruce Momjian wrote:
> On Sat, Mar  1, 2014 at 01:35:45PM -0500, Noah Misch wrote:
> > Having that said, I can appreciate the value of tightening the socket mode for
> > a bit of *extra* safety:
> > 
> > --- a/src/test/regress/pg_regress.c
> > +++ b/src/test/regress/pg_regress.c
> > @@ -2299,4 +2299,5 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
> >          fputs("\n# Configuration added by pg_regress\n\n", pg_conf);
> >          fputs("max_prepared_transactions = 2\n", pg_conf);
> > +        fputs("unix_socket_permissions = 0700\n", pg_conf);
> 
> Pg_upgrade has this exact same problem, and take the same approach.  You
> might want to look in pg_upgrade/server.c.

Thanks.  To avoid socket path length limitations, I lean toward placing the
socket temporary directory under /tmp rather than placing under the CWD:

http://www.postgresql.org/message-id/flat/20121129223632.GA15016@tornado.leadboat.com

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Triggers on foreign tables
Next
From: Kouhei Kaigai
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)