[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: Ok, I've committed the patch. Hopefully this will also fix any similar issues. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker __

[issue21207] urandom persistent fd - not re-openned after fd close

Roundup Robot added the comment: New changeset a66524ce9551 by Antoine Pitrou in branch '3.4': Issue #21207: Detect when the os.urandom cached fd has been closed or replaced, and open it anew. http://hg.python.org/cpython/rev/a66524ce9551 New changeset d3e8db93dc18 by Antoine Pitrou in branch '

[issue21207] urandom persistent fd - not re-openned after fd close

Charles-François Natali added the comment: > Updated patch using an anonymous struct. LGTM! -- ___ Python tracker ___ ___ Python-bugs

[issue21207] urandom persistent fd - not re-openned after fd close

Daniel Black added the comment: fine by me. was just a thought -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: > maybe you've thought and dismissed this already but os.close could > call dev_urandom_close for the urandom_fd. Then there's no fstat calls > in every random access. That's fine if os.close() is indeed used to close fd, but not if some third-party library uses

[issue21207] urandom persistent fd - not re-openned after fd close

Daniel Black added the comment: maybe you've thought and dismissed this already but os.close could call dev_urandom_close for the urandom_fd. Then there's no fstat calls in every random access. As a sweeping close all isn't going to occur that often and extra open probably isn't that much over

[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: Updated patch using an anonymous struct. -- Added file: http://bugs.python.org/file35006/urandom_fd_reopen2.patch ___ Python tracker ___ ___

[issue21207] urandom persistent fd - not re-openned after fd close

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org

[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: Hmm, the patch doesn't release the GIL around the fstat() calls, I wonder if that's necessary. -- ___ Python tracker ___ __

[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: Here is a proposed patch (with tests). -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file34965/urandom_fd_reopen.patch ___ Python tracker _

[issue21207] urandom persistent fd - not re-openned after fd close

Charles-François Natali added the comment: I was expecting to see such a report :-) I'm al for the st_ino+st_dev check, it can't hurt. But everybody must keep in mind that if another thread messes with the FD between the check and the read, there's nothing we can do... --

[issue21207] urandom persistent fd - not re-openned after fd close

Changes by Daniel Black : -- nosy: +grooverdan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue21207] urandom persistent fd - not re-openned after fd close

Raymond Hettinger added the comment: Christian, do you see a security risk with the proposed change? -- nosy: +christian.heimes, rhettinger ___ Python tracker ___ ___

[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: Well, on the one hand this does sound like a valid use case. On the other hand, once the urandom file descriptor is closed by third-party code, it can very well be re-opened to point to another file, and then os.urandom() will start behaving in a very bad way.

[issue21207] urandom persistent fd - not re-openned after fd close

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 exam

[issue21207] urandom persistent fd - not re-openned after fd close

STINNER Victor 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()" Which project or Python module does that? Can you show me the code? -- nosy: +haypo ___ Python t

[issue21207] urandom persistent fd - not re-openned after fd close

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 "import os;os.urandom(1

[issue21207] urandom persistent fd - not re-openned after fd close

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 anyway to reopen it such that ot

[issue21207] urandom persistent fd - not re-openned after fd close

Antoine Pitrou added the comment: Well, if a third-party library decides to close fds it doesn't own, that library should have a bug reported to it. -- ___ Python tracker ___ __

[issue21207] urandom persistent fd - not re-openned after fd close

Changes by STINNER Victor : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue21207] urandom persistent fd - not re-openned after fd close

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 urandom in http://bugs.pytho