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

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

doc/src/sgml/regress.sgml

@@ -56,25 +56,31 @@ make 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>make 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>make
+    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>