If a libuuid application is unable to access /dev/random or /dev/urandom
then uuid generation by uuid_generate falls back to uuid_generate_time.
This could happen in chroot or container environments.
The function ul_random_get_bytes from lib/randutils.c uses getrandom if
it is available. This could either mean that the libuuid application
skips good random bytes because the character special files do not exist
or the application trusts in good random bytes just because these files
are accessible but not necessarily usable, e.g. limit of open file
descriptors reached, lack of data, kernel without getrandom, etc.
This commit modifies ul_random_get_bytes to return an integer which
indicates if random bytes are of good quality (0) or not (1). Callers
can decide based on this information if they want to discard the random
bytes. Only libuuid checks the return value. I decided to return 1
instead of -1 because -1 feels more like an error, but weak random bytes
can be totally fine.
Another issue is that getrandom sets errno to specific values only in
case of an error, i.e. with return value -1. Set errno to 0 explicitly
if getrandom succeeds so we do not enter the fallback routine for
ENOSYS by mistake. I do not think that this is likely to happen, but it
really depends on possible wrapper function supplied by a C library.
Signed-off-by: Samanta Navarro <ferivoz@riseup.net>
The mcookie should reuse existing code, and there is definitely no need
to prefer /dev/random for this utility. See reference for explanation
about later statement.
References: http://www.2uo.de/myths-about-urandom/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This reverts commit 6126f7a53c
and fixes the double open and leaking descriptor in a different way,
that is by using newly introduced function 'have_random_source()'
to check whether good random source is available while deciding
which uuid type to generate (random/time).
This is better than calling random_get_fd() twice, passing the file
descriptor down the stack and reusing it in next call to
random_get_fd().
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
We are opening /dev/urandom twice in uuid_generate(): first to check if
the file is available and then later __uuid_generate_random() again to
actually get the random data. Moreover, descriptor from the first open
is leaking.
Fix by passign the descriptor down the stack and reusing it there.
References: http://marc.info/?l=util-linux-ng&m=133406051131131&w=2
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
Add a random number(s) generator specific file. The intial functions are based
on what libuuid provide. I did some modifications like avoid WIN32 checks - this
is util-LINUX.
[kzak@redhat.com: - move jrand_seed to lib/randutils.c
- use TLS for jrand_seed (like original code from libuuid)
- use size_t for buffer sizes
- add close() to random_get_bytes]
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Signed-off-by: Karel Zak <kzak@redhat.com>
Samanta Navarro
Sami Kerola
Karel Zak
Petr Uzel
Davidlohr Bueso