rand_unix.c: open random devices on first use only
authorDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Thu, 18 Oct 2018 11:27:14 +0000 (13:27 +0200)
committerDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Thu, 8 Nov 2018 15:38:26 +0000 (16:38 +0100)
commit8cfc19716c22dac737ec8cfc5f7d085e7c37f4d8
tree4eb1e36de2011e3f4f0390b943be93303e11a65e
parent1901516a4ba909fff12e0e7815aa2d499f4d6d67
rand_unix.c: open random devices on first use only

Commit c7504aeb640a (pr #6432) fixed a regression for applications in
chroot environments, which compensated the fact that the new OpenSSL CSPRNG
(based on the NIST DRBG) now reseeds periodically, which the previous
one didn't. Now the reseeding could fail in the chroot environment if the
DEVRANDOM devices were not present anymore and no other entropy source
(e.g. getrandom()) was available.

The solution was to keep the file handles for the DEVRANDOM devices open
by default. In fact, the fix did more than this, it opened the DEVRANDOM
devices early and unconditionally in rand_pool_init(), which had the
unwanted side effect that the devices were opened (and kept open) even
in cases when they were not used at all, for example when the getrandom()
system call was available. Due  to a bug (issue #7419) this even happened
when the feature was disabled by the application.

This commit removes the unconditional opening of all DEVRANDOM devices.
They will now only be opened (and kept open) on first use. In particular,
if getrandom() is available, the handles will not be opened unnecessarily.

This change does not introduce a regression for applications compiled for
libcrypto 1.1.0, because the SSLEAY RNG also seeds on first use. So in the
above constellation the CSPRNG will only be properly seeded if it is happens
before the forking and chrooting.

Fixes #7419

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7437)
crypto/rand/rand_unix.c