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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers