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>
e4be3ee01d