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

As announced with last week's releases, use of trust authentication in the
"make check" temporary database cluster makes it straightforward to hijack the
OS user account involved.  The prerequisite is another user account on the
same system.  The solution we discussed on security@postgresql.org was to
switch to md5 authentication with a generated, strong password.

This patch adds a pg_genpassword program, which pg_regress.c and the
pg_upgrade test drivers use to generate password files for initdb and psql.
It is essentially a portable "head -c16 /dev/urandom | xxd -p".  I have it
installing to $(bindir) for the benefit of out-of-tree test suites that create
temporary clusters.  $(pgxsdir)/$(subdir), where we install pg_regress itself,
was another candidate.  This is the first core need for high-entropy random
sequences, so I adapted px_acquire_system_randomness() to libpgport as
secure_rand_bytes().

The implementation of secure_rand_bytes() prompted the question of what to do
when there's no adequate entropy source, such as on Unix-like systems with no
/dev/urandom.  OpenSSL and OpenSSH give up; you're expected to install EGD or
PRNGD.  I made the test drivers recognize a PGTESTPWFILE environment variable.
It should name a file suitable as input to "initdb --pwfile=...".  When
present, the test drivers will skip attempting to generate a password and will
use the one in that file.  I don't see any platforms on the buildfarm that
will need to use PGTESTPWFILE, but I bet at least Tom's old HP-UX system will
need it.

The dblink and postgres_fdw tests rely on a postmaster environment such that
superuser sessions can make new bootstrap superuser connections without a
password.  pg_regress achieves this by starting the server with the same
PGPASSFILE setting as it uses for psql.  Secure "make -C contrib installcheck"
rigs will need to do something similar.

Needing some conversion from random bytes to a text password, I moved the hex
encoder from encode.c to src/port/pgencode.c.  That place will be suitable for
the base64 encoder, too, when other code needs it (pgcrypto already contains a
duplicate base64 implementation).  Though the new libpgport functions fit
better in libpgcommon, since this is slated for back-patch, I chose the
library available in all supported versions.

Peripheral to the topic at hand, I sought and did not find evidence of
contemporary systems where an unprivileged user can examine the environment
variables of another user's processes.  What's a non-ancient system for which
the warning documented for the PGPASSWORD environment variable is apropos?

Thanks,
nm

--
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com