Re: [libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs
* Eric Blake:
Does anyone know if glibc guarantees that opendir/readdir in between
multi-threaded fork() and exec() is safe, even though POSIX does not
guarantee that safety in general?
glibc supports malloc after multi-threaded fork as an extension (or as
a bug, because it makes malloc not async-signal-safe).
Lots of programs depend on this. OpenJDK even calls malloc after
vfork, which is not officially supported (but of course we can't break
OpenJDK).
I know that one approach to avoid
having to close all fds is religiously using O_CLOEXEC everywhere (so
that the race window of having an fd that would leak is not possible),
but that's also an expensive audit, compared to just ensuring that
things are closed after fork(). Are there any other ideas out there
that we should be aware of (and no, pthread_atfork is not a sane idea)?
(various BSD systems have the closefrom() syscall which is more
efficient than lots of close() calls; and Linux may be adding something
similar https://lwn.net/Articles/789023/), Is there any saner way to
close all unneeded fds that were not properly marked O_CLOEXEC by an
application linking against a multithreaded lib that must perform fork/exec?
I tried to add getdents64 (which got committed, but may yet move from
<unistd.h> to <dirent.h>, to match musl) and <sys/direntries.h> (which
did not) in glibc 2.30. Those interfaces are async-signal-safe
(except on some MIPS variants, where getdents64 has complex
emulation).
If you do not want to use opendir/readdir, issuing getdents64 directly
and parsing the buffer is your best option right now. (Lowering the
RLIMIT_NOFILE limit does not enable probing for stray descriptors,
unfortunately.) But opendir/readdir after fork should be fine,
really.