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

[Florian Weimer <fweimer at redhat dot com>]

On 08/29/2014 01:46 AM, Steven Stewart-Gallus 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).

Do you eventually call exec?

If yes, it's could be worthwhile to extend posix_spawn, assuming that 
agreement can be reached about a useful set of new actions.

--
Florian Weimer / Red Hat Product Security