Re: Securing "make check" (CVE-2014-0067) - Mailing list pgsql-hackers
From | Christoph Berg |
---|---|
Subject | Re: Securing "make check" (CVE-2014-0067) |
Date | |
Msg-id | 20140329090455.GA24531@msgid.df7cb.de Whole thread Raw |
In response to | Re: Securing "make check" (CVE-2014-0067) (Noah Misch <noah@leadboat.com>) |
Responses |
Re: Securing "make check" (CVE-2014-0067)
|
List | pgsql-hackers |
Re: Noah Misch 2014-03-24 <20140323230420.GA4139279@tornado.leadboat.com> > 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. Fwiw, to relocate the pg_regress socket dir, there is already the possibility to run make check EXTRA_REGRESS_OPTS="--host=/tmp". (With the pending fix I sent yesterday to extend this to contrib/test_decoding.) > > 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. We've been putting a small patch into pg_upgrade in Debian to work around too long socket paths generated by pg_upgrade during running the testsuite (and effectively on end user systems, but I don't think anyone is using such long paths there). A similar code bit could be put into pg_regress itself. Fix for: connection to database failed: Unix-domain socket path "/build/buildd-postgresql-9.3_9.3~beta1-1-i386-mHjRUH/postgresql-9.3-9.3~beta1/build/contrib/pg_upgrade/.s.PGSQL.50432" istoo long (maximum 107 bytes) See also: http://lists.debian.org/debian-wb-team/2013/05/msg00015.html --- a/contrib/pg_upgrade/option.c +++ b/contrib/pg_upgrade/option.c @@ -422,6 +422,11 @@ get_sock_dir(ClusterInfo *cluster, bool cluster->sockdir = pg_malloc(MAXPGPATH); if (!getcwd(cluster->sockdir, MAXPGPATH)) pg_fatal("cannot find current directory\n"); +#ifndef UNIX_PATH_MAX +#define UNIX_PATH_MAX 108 +#endif + if (strlen(cluster->sockdir) > UNIX_PATH_MAX - sizeof(".s.PGSQL.50432")) + strcpy(cluster->sockdir, "/tmp"); /* fall back to tmp */ } else { I had proposed that patch here before, but iirc it was rejected on grounds of "not a PostgreSQL problem". Christoph -- cb@df7cb.de | http://www.df7cb.de/
pgsql-hackers by date: