Steven Hiscocks added the comment:
Issue where I hit this is in Fail2Ban:
https://github.com/fail2ban/fail2ban/issues/687
Lines of code where this occurs:
https://github.com/fail2ban/fail2ban/blob/1c65b946171c3bbc626ddcd9320ea2515018677b/fail2ban/server/server.py#L518-530
There are other
Steven Hiscocks added the comment:
Just to add for those interested: a possible work around solution is using
"os.path.sameopenfile" to check fds against another known fd for urandom.
And for those wish to have a bit of fun (and maybe a security consideration):
python -c "impor
Steven Hiscocks added the comment:
I agree in part, but it's quite common to close fd's in some cases like in a
child process after using "os.fork()". There is no way, as far as I'm aware, to
identify which fd is associated with /dev/urandom to keep it open; or anywa
New submission from Steven Hiscocks:
I've seen an issue with using urandom on Python 3.4. I've traced down to fd
being closed (not by core CPython, but by third party library code). After
this, access to urandom fails.
I assume this is related to persistent fd for urando
