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

Carlos O'Donell carlos@redhat.com
Fri Aug 29 19:00:00 GMT 2014

On 08/29/2014 02:42 PM, Steven Stewart-Gallus wrote:
>> The only guarantee glibc provides are those that are in POSIX.
>> That is all we provide because nobody has ever asked for more.
> Fair enough, I guess.
>> 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.
> Well the heart of my sandboxing code is on Gitorious at
> https://gitorious.org/linted/linted/source/56b96eab69a9fa37707bf92fe897c91a96ddc589:src/spawn/spawn.c.
> As you can see, it performs a number of functions.  However, I am
> still cleaning it up a bit to remove unneeded async-signal-safety
> problems such as a memory allocation.
> I think the only functions I absolutely need to be safe after a fork
> from a threaded program are unshare, mount, syscall (for pivot_root
> only), umount2, setgroups, cap_set_proc and prctl.

That's a good start.

I would estimate:

unshare - syscall stub, AS-safe
mount - syscall stub, AS-safe
syscall - assembly stub, pure function, AS-safe
umount2 - syscall stub, AS-safe
setgroups - complex, AS-unsafe
cap_set_proc - unknown
prctl - syscall stub, AS-safe

> Also technically I also need errno which should be async-signal-safe
> everywhere but I don't think is actually explicitly listed in any
> standard. Aas a side note, __errno_location lacks a possibly needed
> volatile qualifier but I'm not sure if that matters except in entirely
> artificial and bizarre cases.
> It would be technically possible for me to work around a setpriority
> that is not safe after a fork from a threaded program but it would be
> annoying and difficult.
> It would be convenient for me for assert, memmove, pthread_sigmask and
> getpriority to be safe after a fork from a threaded program but I can
> work around those.

Some of these are already AS-safe. The glibc manual has AS-safety
information and at least memmove is AS-safe :}

> Also how do you think I could get more people to look at the topic and
> contribute their specific needs?  If you thought it'd help I guess I
> could post on mailing lists for projects such as systemd, LXC and
> Docker to request some comments.  Do you have any ideas about who else
> to contact?

That's exactly the list I had in mind. In fact I know LXC already wants
a new clone variant so be careful not to confuse topics.

I might extend that to the Chrome team at Google since they sandbox
things. Find someone you know at Google, try Jeff Bailey or Grant Grundler
or Roland McGrath to find someone who knows someone who wrote the sandbox

The next step would be to stick the requirements on the glibc wiki on
some page we can group edit and review.


More information about the Libc-help mailing list