On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote: > Marko Kreen <mark...@gmail.com> writes: > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <n...@leadboat.com> wrote: > >> How about instead calling RAND_cleanup() after each backend fork? > > > Attached is a patch that adds RAND_cleanup() to fork_process(). > > I remain unconvinced that this is the best solution. Anybody else have > an opinion?
I'd describe it as the clearly-secure solution. The biggest hazard I see is the drain on system entropy. A system having only a blocking /dev/random could suddenly find itself entropy-exhausted after installing the minor upgrade. Backends could block waiting for system entropy to accumulate. That's not directly a problem on Linux. However, if other programs on the system read from /dev/random, the pressure from PostgreSQL's /dev/urandom usage may make those programs wait longer for entropy. I'm also comfortable with the security of Marko's original proposal, modulo it happening in each backend shortly after fork, not merely in pgcrypto. OpenSSL's ssl module uses a similar method, and one of the papers I cited describes it. (If anything, OpenSSL is less cautious. It uses time(), not gettimeofday().) The performance characteristics of this approach are easier to guess: one system call if we use MyProcPid + gettimeofday(), zero if we use MyProcPid + MyStartTime. You proposed mixing gettimeofday() into the postmaster's entropy pool after each fork. I wouldn't be too concerned if we did it that way, but my quick literature review did not turn up any similar ideas. Given that this is strictly more expensive than the previous method, I don't recommend it. Overall, I'd recommend mixing in MyProcPid and MyStartTime after each fork. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers