Protect fork/exec on targets that don't support atomic CLOEXEC #14674
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In addition to the standard
O_CLOEXEC
flag toopen
(POSIX.1-2008), all modern POSIX systems implement non-standard syscalls (accept4
,dup3
andpipe2
) along with theSOCK_CLOEXEC
flag, that atomically create file descriptors with theFD_CLOEXEC
flag.A notable exception is Darwin that only implements
O_CLOEXEC
.We thus have to support falling back to
accept
,dup2
andpipe
that won't setFD_CLOEXEC
orSOCK_CLOEXEC
atomically, which creates a time window during which another thread may fork the process beforeFD_CLOEXEC
is set, which will leak the file descriptor to a child process.This patch introduces a RWLock to prevent fork/exec in such situations.
Follow up of #14672, #14673 and #14675.
Prior art: Go does exactly that.