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

From: Noah Misch <noah(at)leadboat(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Securing "make check" (CVE-2014-0067)
Date: 2014-03-06 03:56:36
Message-ID: 20140306035636.GB3527902@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)GA15016(at)tornado(dot)leadboat(dot)com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2014-03-06 04:22:03 Re: Custom Scan APIs (Re: Custom Plan node)
Previous Message Noah Misch 2014-03-06 03:36:44 Re: Triggers on foreign tables