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: "Carlos O'Donell" <carlos at redhat dot com>, Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>, "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Sun, 31 Aug 2014 09:12:19 +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> <CAE2sS1johA-QwqCC3LmiXmjfft14qP0GYY+EpXqTDT95Vn5RkQ at mail dot gmail dot com> <fb929a1751b9 dot 5400c9ac at langara dot bc dot ca> <5400CDB0 dot 80909 at redhat dot com>
On 08/29/2014 09:00 PM, Carlos O'Donell wrote:
setgroups - complex, AS-unsafe
This could be made safe after fork with little effort because the thread
count is 1 at this point, and the setxid magic isn't needed.
cap_set_proc - unknown
This function just calls capset, which is just a system call wrapper.
It affects thread attributes in a potentially irrevocable way (just as
the setgroups or setresuid system calls), so calling it
async-signal-safe is a bit of a stretch, but it's safe after fork.
--
Florian Weimer / Red Hat Product Security