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

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 20140329090455.GA24531@msgid.df7cb.de
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
Ответы Re: Securing "make check" (CVE-2014-0067)  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: "Erik Rijkers"
Дата:
Сообщение: Re: trgm regex index peculiarity
Следующее
От: Robert Haas
Дата:
Сообщение: Re: psql \d+ and oid display