Noah Misch <n...@leadboat.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 secur...@postgresql.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
