Re: Re: Hangup calling setuid() from vfork() child

[Rich Felker <dalias@libc.org>]

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