Document risks of "make check" in the regression testing instructions.

tglsfdc · tglsfdc · commit 369c229d2f35 · 2014-02-17T11:24:48.000-05:00
Since the temporary server started by "make check" uses "trust" authentication, another user on the same machine could connect to it as database superuser, and then potentially exploit the privileges of the operating-system user who started the tests. We should change the testing procedures to prevent this risk; but discussion is required about the best way to do that, as well as more testing than is practical for an undisclosed security problem. Besides, the same issue probably affects some user-written test harnesses. So for the moment, we'll just warn people against using "make check" when there are untrusted users on the same machine. In passing, remove some ancient advice that suggested making the regression testing subtree world-writable if you'd built as root. That looks dangerously insecure in modern contexts, and anyway we should not be encouraging people to build Postgres as root. Security: CVE-2014-0067
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
@@ -55,25 +55,31 @@ gmake check
    <quote>failure</> represents a serious problem.
   </para>
 
+  <warning>
    <para>
-    Because this test method runs a temporary server, it will not work
-    when you are the root user (since the server will not start as root).
-    If you already did the build as root, you do not have to start all
-    over.  Instead, make the regression test directory writable by
-    some other user, log in as that user, and restart the tests.
-    For example:
-<screen>
-<prompt>root# </prompt><userinput>chmod -R a+w src/test/regress</userinput>
-<prompt>root# </prompt><userinput>su - joeuser</userinput>
-<prompt>joeuser$ </prompt><userinput>cd <replaceable>top-level build directory</></userinput>
-<prompt>joeuser$ </prompt><userinput>gmake check</userinput>
-</screen>
-    (The only possible <quote>security risk</quote> here is that other
-    users might be able to alter the regression test results behind
-    your back.  Use common sense when managing user permissions.)
+    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.
    </para>
+  </warning>
+
    <para>
-    Alternatively, run the tests after installation.
+    Because this test method runs a temporary server, it will not work
+    if you did the build as the root user, since the server will not start as
+    root.  Recommended procedure is not to do the build as root, or else to
+    perform testing after completing the installation.
    </para>
 
    <para>
