Secure Unix-domain sockets of "make check" temporary clusters.

nmisch · nmisch · commit 8cade31dc590 · 2014-03-29T01:30:13.000-04:00
Any OS user able to access the socket can connect as the bootstrap superuser and in turn execute arbitrary code as the OS user running the test. Protect against that by placing the socket in the temporary data directory, which has mode 0700 thanks to initdb. Back-patch to 8.4 (all supported versions). The hazard remains wherever the temporary cluster accepts TCP connections, notably on Windows. Attempts to run "make check" from a directory with a long name will now fail. An alternative not sharing that problem was to place the socket in a subdirectory of /tmp, but that is only secure if /tmp is sticky. The PG_REGRESS_SOCK_DIR environment variable is available as a workaround when testing from long directory paths. As a convenient side effect, this lets testing proceed smoothly in builds that override DEFAULT_PGSOCKET_DIR. Popular non-default values like /var/run/postgresql are often unwritable to the build user. Security: CVE-2014-0067
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
@@ -57,21 +57,14 @@ gmake check
 
   <warning>
    <para>
-    This test method starts a temporary server, which is configured to accept
-    any connection originating on the local machine.  Any local user can gain
-    database superuser privileges when connecting to this server, and could
-    in principle exploit all privileges of the operating-system user running
-    the tests.  Therefore, it is not recommended that you use <literal>gmake
-    check</> on machines shared with untrusted users.  Instead, run the tests
-    after completing the installation, as described in the next section.
-   </para>
-
-   <para>
-    On Unix-like machines, this danger can be avoided if the temporary
-    server's socket file is made inaccessible to other users, for example
-    by running the tests in a protected chroot.  On Windows, the temporary
-    server opens a locally-accessible TCP socket, so filesystem protections
-    cannot help.
+    On systems lacking Unix-domain sockets, notably Windows, this test method
+    starts a temporary server configured to accept any connection originating
+    on the local machine.  Any local user can gain database superuser
+    privileges when connecting to this server, and could in principle exploit
+    all privileges of the operating-system user running the tests.  Therefore,
+    it is not recommended that you use <literal>gmake check</> on an affected
+    system shared with untrusted users.  Instead, run the tests after
+    completing the installation, as described in the next section.
    </para>
   </warning>
 
@@ -111,6 +104,17 @@ gmake MAX_CONNECTIONS=10 check
     runs no more than ten tests concurrently.
    </para>
 
+   <para>
+    To protect your operating system user account, the test driver places the
+    server's socket in a relative subdirectory inaccessible to other users.
+    Since most systems constrain the length of socket paths well
+    below <literal>_POSIX_PATH_MAX</>, testing may fail to start from a
+    directory with a long name.  Work around this problem by pointing
+    the <envar>PG_REGRESS_SOCK_DIR</> environment variable to a substitute
+    socket directory having a shorter path.  On a multi-user system, give that
+    directory mode <literal>0700</>.
+   </para>
+
   <para>
    To run the tests after installation<![%standalone-ignore;[ (see <xref linkend="installation">)]]>,
    initialize a data area and start the
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
@@ -106,6 +106,7 @@ static const char *progname;
 static char *logfilename;
 static FILE *logfile;
 static char *difffilename;
+static char *sockdir;
 
 static _resultmap *resultmap = NULL;
 
@@ -763,8 +764,7 @@ initialize_environment(void)
 		 * the wrong postmaster, or otherwise behave in nondefault ways. (Note
 		 * we also use psql's -X switch consistently, so that ~/.psqlrc files
 		 * won't mess things up.)  Also, set PGPORT to the temp port, and set
-		 * or unset PGHOST depending on whether we are using TCP or Unix
-		 * sockets.
+		 * PGHOST depending on whether we are using TCP or Unix sockets.
 		 */
 		unsetenv("PGDATABASE");
 		unsetenv("PGUSER");
@@ -776,7 +776,24 @@ initialize_environment(void)
 		if (hostname != NULL)
 			doputenv("PGHOST", hostname);
 		else
-			unsetenv("PGHOST");
+		{
+			sockdir = getenv("PG_REGRESS_SOCK_DIR");
+			if (!sockdir)
+			{
+				/*
+				 * Since initdb creates the data directory with secure
+				 * permissions, we place the socket there.  This ensures no
+				 * other OS user can open our socket to exploit our use of
+				 * trust authentication.  Compared to using the compiled-in
+				 * DEFAULT_PGSOCKET_DIR, this also permits testing to work in
+				 * builds that relocate it to a directory not writable to the
+				 * build/test user.
+				 */
+				sockdir = malloc(strlen(temp_install) + sizeof("/data"));
+				sprintf(sockdir, "%s/data", temp_install);
+			}
+			doputenv("PGHOST", sockdir);
+		}
 		unsetenv("PGHOSTADDR");
 		if (port != -1)
 		{
@@ -2203,10 +2220,11 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
 		 */
 		header(_("starting postmaster"));
 		snprintf(buf, sizeof(buf),
-				 SYSTEMQUOTE "\"%s/postgres\" -D \"%s/data\" -F%s -c \"listen_addresses=%s\" > \"%s/log/postmaster.log\" 2>&1" SYSTEMQUOTE,
-				 bindir, temp_install,
-				 debug ? " -d 5" : "",
-				 hostname ? hostname : "",
+				 SYSTEMQUOTE "\"%s/postgres\" -D \"%s/data\" -F%s "
+				 "-c \"listen_addresses=%s\" -k \"%s\" "
+				 "> \"%s/log/postmaster.log\" 2>&1" SYSTEMQUOTE,
+				 bindir, temp_install, debug ? " -d 5" : "",
+				 hostname ? hostname : "", sockdir ? sockdir : "",
 				 outputdir);
 		postmaster_pid = spawn_process(buf);
 		if (postmaster_pid == INVALID_PID)
