mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-27 08:39:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Tom Lane 2014-02-17 11:24:32 -05:00
parent 01824385ae
commit 6ef325429c
1 changed files with 23 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/src/sgml/regress.sgml
View File

@ -56,25 +56,31 @@ make check
<quote>failure</> represents a serious problem.
</para>
<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>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>
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.)
</para>
<para>
Alternatively, run the tests after installation.
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>