[libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs

[Florian Weimer]

* 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.