gspawn doesn't set CLOEXEC if close_range fails unexpectedly
Over in https://github.com/ostreedev/ostree/issues/2495 I was debugging an issue that caused a test to hang after calling g_spawn_sync
. What happens is that the test is run in a Docker container and seccomp ends up causing close_range
to error with EPERM
.
Currently if close_range
fails with ENOSYS
or EINVAL
then it will fall back to digging through /proc/self/fd
or other means of finding open FDs. However, if it doesn't fail with one of those errors, then it silently carries in without doing anything. I feel like there are a couple possible improvements there:
-
Even though it's wrong, include
EPERM
in the list of fallback errors since seccomp setup to error withEPERM
by default is a common occurrence in Docker or other sandboxing systems. -
Make it fallback regardless of the error, possibly with some message about how
close_range
failed unexpectedly. -
Make unexpected
close_range
errors fatal a lag_assert
,g_error
org_critical
.
As it is you might just get a hang with no indication of what the issue is.