[issue47260] os.closerange() can be no-op in a seccomp sandbox

miss-islington added the comment: New changeset 89697f7374ea947ebe8e36131e2d3e21fff6fa1d by Miss Islington (bot) in branch '3.10': bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox (GH-32418)

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Gregory P. Smith added the comment: Good catch. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +30445 pull_request: https://github.com/python/cpython/pull/32420 ___ Python tracker

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Gregory P. Smith added the comment: New changeset 1c8b3b5d66a629258f1db16939b996264a8b9c37 by Alexey Izbyshev in branch 'main': bpo-47260: Fix os.closerange() potentially being a no-op in a seccomp sandbox (GH-32418)

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by Alexey Izbyshev : -- keywords: +patch stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Alexey Izbyshev added the comment: > It's been years now and that hasn't happened, even with more recent flag > additions. I think it's safe to say it won't, and such a fallback upon error > won't put us back into a bogus pre-close_range situation where we're > needlessly close()ing a bunch

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Change by Alexey Izbyshev : -- keywords: +patch pull_requests: +30443 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32418 ___ Python tracker ___

[issue47260] os.closerange() can be no-op in a seccomp sandbox

Kyle Evans added the comment: Sure, sounds good to me. The original theory (IIRC, I've slept many times since then :-)) was that we already know first/last are valid and there are no other defined errors, so 'other errors' must be because close_range has started percolating up something

[issue47260] os.closerange() can be no-op in a seccomp sandbox

New submission from Alexey Izbyshev : After #40422 _Py_closerange() assumes that close_range() closes all file descriptors even if it returns an error (other than ENOSYS): if (close_range(first, last, 0) == 0 || errno != ENOSYS) { /* Any errors encountered while closing file