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

[Rich Felker <dalias@libc.org>]

On Mon, Sep 30, 2019 at 07:39:28PM +0200, Markus Wichmann wrote:
> On Mon, Sep 30, 2019 at 08:29:16AM -0700, Joshua Hudson wrote:
> > If there is more than one thread and vfork() calls setuid(), musl libc hangs up.
> >
> > void *thfunction(void*ig) {sleep(1000);returnNULL;}
> >
> > int main()
> > {
> >     pthread_t id;
> >     pthread_create(&id, NULL, thfunction, NULL);
> >     if (vfork() == 0) {
> >         setuid(0); /* hangup */
> >         _exit(0);
> >     }
> > }
> 
> That is an interesting interaction between threads and vfork().
> 
> The child process has only one thread, but it doesn't know that. It also
> can't write it down, since it is sharing memory with the parent (it
> would overwrite the parent's variables).
> 
> POSIX no longer defines vfork(), and therefore does not define any
> safety attributes for it. Is it reasonable to define vfork() as unusable
> in a multithreaded process? Calling something as intricate as
> __synccall() in a vfork() child is going to corrupt memory on a large
> scale.

It's simpler than that. The (retired) specification for vfork did not
allow anything but _exit or execve in the child after vfork, so the
issue doesn't arise and it works perfectly fine with threads as long
as you follow the requirement.

> posix_spawn() circumvents the problem by calling the system calls
> directly, BTW.

Yes, posix_spawn should be used if possible. It even has an attribute
to reset ids to the real ones.

Rich