www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die." <ron...@innovation.ch>
Subject Re: mod_auth-any/4967: Can't read from /dev/random
Date Sun, 19 Sep 1999 23:10:01 GMT
The following reply was made to PR mod_auth-any/4967; it has been noted by GNATS.

From: "Life is hard, and then you die." <ronald@innovation.ch>
To: apbugs@apache.org
Cc:  Subject: Re: mod_auth-any/4967: Can't read from /dev/random
Date: Mon, 20 Sep 1999 01:05:47 +0200 (MET DST)

 > > Well, ok, I'll have to change to raw read as suggested in the report.
 > Hmm.. let's see. You propably are doing a read for _each_ and every child
 > as you are starting up.. whichis propably why the random(4) gets exhausted
 > so quickly during server init.
 No, no, no. I only get it once, during module init, the second time it
 goes through. I ran a simple test program on taz and what I see is
 always the same:
 read 0 bytes
 read 1 bytes
 read 0 bytes
 read 0 bytes
 read 1 bytes
 read 0 bytes
 read 0 bytes
 read 1 bytes
 read 0 bytes
 (this is doing a tight loop around read()). Dunno why I see this
 behaviour on FreeBSD, but maybe somebody else is using a lot of random
 numbers (tcp?). In any case, it gets the 20 bytes in a couple seconds,
 so it's not that bad. A blocking /dev/random (like Linux has) would be
 more efficient, though.
 > Now all we require is an unpredictable number. It does not need to be
 > random at all. Perhaps during initial config we can _once_ read the value
 > and then use a one way function, say md5, to seed each child on the second
 > init of the actual forked of processes; just adding a few bits (say the
 > PID) is enough as long as the function is one way enough. MD5 should be.
 The children don't each need their own generator, and in fact need to
 all have the same secret, otherwise they can't check the nonce if the
 request comes back on a different connection/child.

View raw message