From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Securing "make check" (CVE-2014-0067) |
Date: | 2014-03-01 17:29:38 |
Message-ID: | 3924.1393694978@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> 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(at)postgresql(dot)org was to
> switch to md5 authentication with a generated, strong password.
Noah is leaving the impression that there was consensus on that approach;
there was not, which is one reason that this patch didn't simply get
committed last week.
There are two big problems with the lets-generate-a-random-password
approach. Noah acknowledged the portability issue of possibly not having
a strong entropy source available. The other issue though is whether
doing this doesn't introduce enough crypto dependency into the core code
to create an export-restrictions hazard. We've kept contrib/pgcrypto
out of core all these years in order to give people a relatively
straightforward solution if they are worried about export laws: just omit
contrib/pgcrypto. But "just omit regression testing" isn't palatable.
In the case of Unix systems, there is a *far* simpler and more portable
solution technique, which is to tell the test postmaster to put its socket
in some non-world-accessible directory created by the test scaffolding.
Of course that doesn't work for Windows, which is why we looked at the
random-password solution. But I wonder whether we shouldn't use the
nonstandard-socket-location approach everywhere else, and only use random
passwords on Windows. That would greatly reduce the number of cases to
worry about for portability of the password-generation code; and perhaps
we could also push the crypto issue into reliance on some Windows-supplied
functionality (though I'm just speculating about that part).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-03-01 18:09:16 | Re: Securing "make check" (CVE-2014-0067) |
Previous Message | Tom Lane | 2014-03-01 17:11:18 | Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements |