]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox (GH...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Fri, 8 Apr 2022 18:10:38 +0000 (11:10 -0700)
committerGitHub <noreply@github.com>
Fri, 8 Apr 2022 18:10:38 +0000 (11:10 -0700)
commit89697f7374ea947ebe8e36131e2d3e21fff6fa1d
tree6439d487c4e98b16b5ef197b7b3a9d56914f5e94
parent69edc30d2b47fe9b95975b1b66214e7473a9ccf5
bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox (GH-32418)

_Py_closerange() currently assumes that close_range() closes
all file descriptors even if it returns an error (other than ENOSYS).
This assumption can be wrong on Linux if a seccomp sandbox denies
the underlying syscall, pretending that it returns EPERM or EACCES.
In this case _Py_closerange() won't close any descriptors at all,
which in the worst case can be a security issue.

Fix this by falling back to other methods in case of any close_range()
error. Note that fallbacks will not be triggered on any problems with
closing individual file descriptors because close_range() is documented
to ignore such errors on both Linux[1] and FreeBSD[2].

[1] https://man7.org/linux/man-pages/man2/close_range.2.html
[2] https://www.freebsd.org/cgi/man.cgi?query=close_range&sektion=2
(cherry picked from commit 1c8b3b5d66a629258f1db16939b996264a8b9c37)

Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru>
Misc/NEWS.d/next/Library/2022-04-08-14-30-53.bpo-47260.TtcNxI.rst [new file with mode: 0644]
Python/fileutils.c