[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190930174311.GS9017@brightrain.aerifal.cx>
Date: Mon, 30 Sep 2019 13:43:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Hangup calling setuid() from vfork() child
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
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.
