[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
