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

Florian Weimer fweimer@redhat.com
Sun Aug 31 07:15:00 GMT 2014

On 08/29/2014 09:16 PM, Steven Stewart-Gallus wrote:
> It's worth noting though that for my own personal use posix_spawn is
> insufficient so adding sandboxing features posix_spawn can only stand
> on its merits to others.

But you do call execve eventually?

> First, I'm making a sort of init system to manage my processes and I
> am using (and I think others might want to use as well) the clunky
> convention of systemd where the main start process that is being
> passed file descriptors is labelled with an environment variable
> called LISTEN_PID.

How does this prevent using posix_spawn?

> Second, I enjoy being able to put in tighter error handling for
> failures during a spawn.  For example, execve can fail by having the
> process killed by an out of memory error and I'm considering adding in
> a horrible hack I figured out to stop a process right after execve so
> I can wait on it and check if it is stopped or killed.

We could add additional error reporting.  The standard trick to detect 
execve success is to read from a pipe whose other end has the 
close-on-exec bit set.

Florian Weimer / Red Hat Product Security

More information about the Libc-help mailing list