From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14753 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hangup calling setuid() from vfork() child Date: Mon, 30 Sep 2019 19:39:28 +0200 Message-ID: <20190930173928.GC2037@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="175580"; 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-14769-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 30 19:39:44 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 1iEzeB-000jaH-Hu for gllmg-musl@m.gmane.org; Mon, 30 Sep 2019 19:39:43 +0200 Original-Received: (qmail 9899 invoked by uid 550); 30 Sep 2019 17:39:40 -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 9878 invoked from network); 30 Sep 2019 17:39:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569865168; bh=IXzi0CLc7E3+2Q81LfOPY4h7doxyIgd5DF1WcdOB9E0=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=htVtDnufuLWxTO4jJx1Y0t+20CychO0pNuBlBhL+nis+UrkdyiO5/HX9BQe+II/w+ Epmw7f//31AuWmV/wdE5BLy+ZLOz1bxczgB70imqBWsG3gMcUX6oRLUJj15E6Peb57 Nm+JuWAQJma+XBU9Y5QNAwJJJx03MIU3IIkCq5GY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:qhZ/w6n1SyiFW9YEGxIpfzci7rVJGYNeB7Ebr7RPC1IMZ2M1Ce9 9KXI4FA+Vv9GhEPvppQMlq/8li9yBSVdwV3GH65ep9d8oe0QfYJypi78pxbPMbNTfeE0oCQ vbg2awlE2iWDK69NVIWyy6ApO1IBOgMq77TlQq6hXP14y5r+uamYavgomGNcw+Wz1T9XcBc ntUjbQfXyxgIaupA3fIgQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:CY5WvmVLFY4=:X3KiWm91t+EqqOiYpS9sNp aBeT6inXXudhCQA25Mzv5P7tclFh9pTpKYdkV6PuPOK4Lmes08mPeAs8Vbt7z3LneSO5tEwTH QFjrvRABVCDcXLQtO8QjfhaRCVhZX0L6PVQU9xF8QPv0L78o1pU+yHiNCpJZMFbkUk1jFtymU Amk4LxnPS1LnBBPdW9kPHuUdOTCjnYOO32NJnrUg+RSE5GutxD9JmdF+5Wlbe+OY0pU/R4u4P SX3VZSnpzv7P6Pb6I0+v7t7SnmVDfo8RE3gyuFumIFJERb0QdjUNnQKSn0qoG9qmOCU8hIe+W OUdAzLYys9/L4pS9Sxpmb3oCzW6kUcWLWYZkb2eYHsetS1DegUei6Pgyli7vHjnlyzL6TvSPH +3hUX2mXGv3UPY4+Ti6J+yHLKL4q8KzzbNWbr/huBcabx0BQiSz0Rjr+BtrH67Nj9lrXey+7W wLx558AK89sEGdz89p8iUWobtxcl6ikg/bOqww6I/vrkGROIqo9ghJeLx97c3zzmXGNFcai1c a2W2PZchS/ZJuw6TF9ku5H5Ddu5LBnAmmuJ75UzVrR99hMfvsm9yiEh/6QHAoKtqHOqwdKDDC Hx4FkB3upfDzhPcdNScM4Un84fPbT9Fro2+I9n4Zj60fKQJke8qBNBQsdNSsMa4QZ2PcCYV/1 T1ESF5bAKZY8QqMPL3FjPAujmlihYDBp4TNup3HdKlc/vmYGbAjp48zTx06v3c8JmcMceo5Fy ytvr8daCQ5D1Uiqm7Jfsoayu9DF0Xep7XRpBpIBKbE6Bhj2RvgggZmgz2OWXT8/on3QiYIOI Xref: news.gmane.org gmane.linux.lib.musl.general:14753 Archived-At: 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 h= angs up. > > void *thfunction(void*ig) {sleep(1000);returnNULL;} > > int main() > { > pthread_t id; > pthread_create(&id, NULL, thfunction, NULL); > if (vfork() =3D=3D 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. posix_spawn() circumvents the problem by calling the system calls directly, BTW. Ciao, Markus