Date: Mon, 30 Sep 2019 18:47:53 -0400 From: Rich Felker <dalias@...c.org> To: Joshua Hudson <joshudson@...il.com> Cc: musl <musl@...ts.openwall.com> Subject: Re: Re: Hangup calling setuid() from vfork() child On Mon, Sep 30, 2019 at 01:45:07PM -0700, Joshua Hudson wrote: > > Basically, the vfork() child is in an invalid state and this cannot be repaired without damaging the parent. > > Works on glibc just fine. > > setuid() is on the list of signal-safe functions. AS-safety is not sufficient to make usage after vfork valid. > http://man7.org/linux/man-pages/man7/signal-safety.7.html > > How about you call getpid() and check if you're on the process you > think you're on before calling __synccall? That could be done, but has ABA issues, and it's just the first step of a game of whack-a-mole and gives a false hope that things that can't work might work. > Somebody else might have done syscall(SYS_fork). Bypassing the fork function to fork by yourself yields a state where you can't use libc. There will be lots of things broken. Thread's idea of its own tid is wrong, robust list wrongly registers ownership of mutexes you don't own, etc. Presently the clone() function has issues like this too. They should be analyzed and addressed at some point. > > So you might want to enable memory overcommit. > > I'm tired of paying the page fault penalty in the parent. It has a > majority of system RAM, and most of the pages are CoW long after the > vfork child hits execve. If at all possible, use posix_spawn. It solves this problem cleanly. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.