From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14757 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Hangup calling setuid() from vfork() child Date: Mon, 30 Sep 2019 22:24:11 +0200 Message-ID: <20190930202411.GD2037@voyager> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82807"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.9.4 (2018-02-28) To: musl@lists.openwall.com Original-X-From: musl-return-14773-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 30 22:24:27 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 1iF2Da-000LRl-RP for gllmg-musl@m.gmane.org; Mon, 30 Sep 2019 22:24:26 +0200 Original-Received: (qmail 23845 invoked by uid 550); 30 Sep 2019 20:24:24 -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 23822 invoked from network); 30 Sep 2019 20:24:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569875052; bh=hz5nN6KtmtBSjXLD8NA3rc2/ElN1j2g0pO2tjkmM4mM=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=QfktCIMCz3UtSbye+iWF3/FSv/ap9mm6vCpzDof4IyXmUWexgpDn1hi5W3PAPlvTK LN4p9SJcrMOdAZiXaWFwvymogxlGCB9Re757Kx9H4ZcWyrwRffGnF4z2cYpvJ2Q7YG W1X5KAnyGU7LteQkP578/Xoh/+LgvLdOD7HdAidg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:3E7bW6ZTmPrE7ko2smz52RaFMieY2RVoOfiFp9J020UpBFtZkry yYo6Z0zRmmZl+nrg9cF2uaKxh1BlFEblxMLqmPYygZyA135kZ3oBGU9mNKn1TmyNKjPX1Ip 432U18lJM8JpbGShnor+FlHaz8LDyZUMWI+17i+fPkZCyylGoNnd4sKpf8WDfMkkaMuNyyN 7ZvKa2Fes1iUqj0C8AcKg== X-UI-Out-Filterresults: notjunk:1;V03:K0:fZXSrnVN+n4=:cfuk4aG2H2FptwExXs24jV 0YWDH+hYXxvF7tWmtsLnruz0F/kqo5RSoP7k80oysvvU5cjdI2RW1awwVCZOGKOfhfTTanKbu /CQjTUHlEnQZ4Caz675t+9iHjODDIlRfTRdk6ShQcfTXmXgIa6vNvQzG/UH2p6XmtL1mUEftd hXPzj34BTcDgSpx3HIXBTDhEjVCcGom/sw4Uhql+l9YLOAn9nH94Eb7boYqol/aGRGaKljeX4 SzyZa+VLPzwbYvo3OQVs5v3az6ZyLMQJPNGvdQpxKV9wSdrmpuwcwVEiKLjBNNbA4I3RK4XaD s1VBrdtrTCHCDYUvjrZc9RiKpPJp3Ms9KGiIBmhZVQPa9ftQhJMvEv/lKvr09kLIE704FKHKY DQr6WkDXOX5Z0N+QCM+2UfDhBcv7tY5hvQzYhDmWmG6EqALyQ8DrJR+GYa3WZryo4rrLBAN3j r6k3YctQmo9+Jxpjjje4Ybi435cDMpmaOD1PKp3x0th+7CSGdvhWP7Lwt6L+h1JwMjLIIYC9d WQHR2W+F0NRftKr82DY41pOflIjTsYCCaWvAxBiUCI+UfFRBwkLRASXEFDVamQ3QzHDj9zWRU mb3cQUZA0+/mkKGhuGNUSqwk6hRtQIODXvB+K2BdlHMAa/mgavjUUhgJ2judjTfTexOjzfyVk A0EDxR3nbMTRILZY6v7B7lpw11+gnO62ztoXlb7lAr+O4fdCs620DvDwpnzzMdBzDIgO1TKnQ T6TGwmMgg5P5XWCDU4MGyMGtqguif7Y2TG0KXb8j0Fan8tp8Fmeo6QFyyqKDcJIHpY/oghP4 Xref: news.gmane.org gmane.linux.lib.musl.general:14757 Archived-At: On Mon, Sep 30, 2019 at 12:57:34PM -0700, Joshua Hudson wrote: > >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. I remembered that while making dinner (after sending my first response). > > I'm reading the man page for vfork and it says what it actually does, th= at > is overlay the child process on the memory of the calling process. > I don't know about you, but my manpage quite clearly states that vfork() is equivalent to clone(CLONE_VM | CLONE_VFORK | SIGCHLD), that is: Parent and child share memory, parent (only the calling thread) is suspended until child execs or exits, and when it does, the child gets a SIGCHLD. If the child process changes anything in memory, that is reflected in the parent. Basically, the vfork() child is in an invalid state and this cannot be repaired without damaging the parent. > posix_spawn can't be used in the originating location, and fork() is > hogging too much memory. fork() only "hogs" that memory which either parent or child modify afterwards. You wish to use vfork(), so I guess the child process won't go long before either exec or exit(), right? So you might want to enable memory overcommit. I don't know about your application, but your options are: - Decouple the child part into another program proper, and use posix_spawn() to call it. - Use fork() and eat the memory cost. - Use clone() and eat the non-portability. Note that clone(CLONE_VFORK) has identical semantics to vfork(), so no calling setuid() there, either. Ciao, Markus