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

On Sat, Mar 01, 2014 at 09:43:19PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > On 03/01/2014 05:10 PM, Tom Lane wrote:
> >> BTW, a different problem with the proposed patch is that it changes
> >> some test cases in ecpg and contrib/dblink, apparently to avoid session
> >> reconnections. That seems likely to me to be losing test coverage.
> >> Perhaps there is no alternative, but I'd like to have some discussion
> >> around that point as well.

connect/test5.pgc has the same number of session reconnections before and
after the patch. The change is to assign passwords to the connection test
accounts and use those passwords during the tests. Test coverage actually
increased there; before, it did not matter whether ecpg conveyed each password
in good order. The dblink change does replace a non-superuser reconnection
with a SET SESSION AUTHORIZATION.

> I believe the point of those changes is that the scaffolding
> only sets up a password for the original superuser, so that connecting
> as anybody else will fail if the test postmaster is configured for
> password auth.

Essentially, yes. You can connect as another user if you assign a password;
the ecpg suite does so. (That user had better be unprivileged.) The dblink
change has a second point. Since the dblink_regression_test role has use of
the dblink_connect_u() function, it needs to be treated as a privileged
account. (I'll add a comment about that.)

> Another issue is that (I presume, haven't checked) "make installcheck"
> on contrib or ecpg will currently fail against a server that's not
> configured for trust auth. Ideally you should be able to do "make
> installcheck" against a reasonably-configured server.

No, I had verified "make installcheck-world" under md5 auth. The setup I
recommend, which I mentioned in the initial message of this thread, is to put
the same PGPASSFILE in the postmaster environment as you put in the "make
installcheck" environment. (It's contrib/dblink and contrib/postgres_fdw that
would otherwise fail.)

nm

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