e4be3ee01d
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> |
||
|---|---|---|
| .. | ||
| man | ||
| src | ||
| COPYING | ||
| Makemodule.am | ||
| uuid.pc.in | ||