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

[Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>]

> 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.

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.

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?

Thank you,
Steven Stewart-Gallus