Re: What is GLibc's policy on what is safe to use after a fork from a multithreaded program?

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Thu, Aug 28, 2014 at 7:46 PM, Steven Stewart-Gallus
<sstewartgallus00@mylangara.bc.ca> wrote:
> POSIX conformance constrains one to only use async-signal-safe
> functions after a fork from a mulithreaded program.  More practically,
> fork fucks with state such as the PID, pending signals, timers,
> outstanding asynchronous I/O operations and locks that threads are
> holding onto.  I need to fork from a multithreaded program and do
> complicated things such as sandboxing a process with non
> async-signal-safe functions such as mount, syscall, unshare, umount2
> and setgroups (I can't exec a helper process because that drops
> capabilities automatically).  I can always check the GLibc source and
> verify if problems will happen but that becomes really painful when
> checking all the system calls I use.  As well, in the future GLibc can
> always change functions to be not safe after a fork from a
> multithreaded program.  What is GLibc's policy on what is safe to use
> after a fork from a multithreaded program?  There doesn't seem to be
> any documentation about this.

The only guarantee glibc provides are those that are in POSIX.

That is all we provide because nobody has ever asked for more.

Sandboxing is a relatively new pattern and thus glibc has never been
asked to help developers with that process.

I am willing to have a broader discussion about this, but I want to
see users talk about what they need and what they are calling *after*
fork.

Cheers,
Carlos.