From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14761 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Hangup calling setuid() from vfork() child Date: Mon, 30 Sep 2019 18:47:53 -0400 Message-ID: <20190930224753.GX9017@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="155326"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl To: Joshua Hudson Original-X-From: musl-return-14777-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 01 00:48:09 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iF4Se-000eHu-T8 for gllmg-musl@m.gmane.org; Tue, 01 Oct 2019 00:48:09 +0200 Original-Received: (qmail 22286 invoked by uid 550); 30 Sep 2019 22:48:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22268 invoked from network); 30 Sep 2019 22:48:05 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14761 Archived-At: 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