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