This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: What is GLibc's policy on what is safe to use after a fork from a multithreaded program?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>
- Cc: libc-help at sourceware dot org
- Date: Sun, 31 Aug 2014 09:15:27 +0200
- Subject: Re: What is GLibc's policy on what is safe to use after a fork from a multithreaded program?
- Authentication-results: sourceware.org; auth=none
- References: <fc17f0ed4ec8 dot 53ffbf5e at langara dot bc dot ca> <54009823 dot 8000007 at redhat dot com> <fb4be6666f4d dot 5400d18f at langara dot bc dot ca>
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