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
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 rep...@bugs.python.org
Charles-François Natali added the comment:
Updated patch using an anonymous struct.
LGTM!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
Antoine Pitrou added the comment:
Updated patch using an anonymous struct.
--
Added file: http://bugs.python.org/file35006/urandom_fd_reopen2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
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
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
Daniel Black added the comment:
fine by me. was just a thought
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list
Changes by Alex Gaynor alex.gay...@gmail.com:
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list mailing
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 rep...@bugs.python.org
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 rep...@bugs.python.org
http://bugs.python.org/issue21207
___
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...
--
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
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
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
Raymond Hettinger added the comment:
Christian, do you see a security risk with the proposed change?
--
nosy: +christian.heimes, rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
Changes by Daniel Black daniel.s...@internode.on.net:
--
nosy: +grooverdan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
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
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
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21207
___
___
Python-bugs-list
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 rep...@bugs.python.org
http://bugs.python.org/issue21207
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
21 matches
Mail list logo
