From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25956 invoked from network); 22 Feb 2023 22:04:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 22 Feb 2023 22:04:56 -0000 Received: (qmail 16051 invoked by uid 550); 22 Feb 2023 22:04:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16026 invoked from network); 22 Feb 2023 22:04:53 -0000 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 86F8D44C1011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1677103481; bh=zXFqOCrXNXdtk2Zt6evaLSSgvmOKzdUX/Z4XOYhtknM=; h=Date:From:To:Cc:Subject:Reply-To:In-Reply-To:References:From; b=Oi3aTyW63REaP/AqqTf6j3DApqcmn6Q/VebiBMrVMITisEVVUW8wV/yH0eAf0EIPy jDKQpbkRsI6AFQOxC+tYCc/dHLgZVQEoNrp4pmYcM4b7cOUWbbpuTZ1RxcF6Z7J4HT HtucwcqfUcOUSSY4i6PWknVIQU7CcX9sFfU7cKy8= MIME-Version: 1.0 Date: Thu, 23 Feb 2023 01:04:41 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com Cc: Florian Weimer Mail-Followup-To: musl@lists.openwall.com In-Reply-To: <20220502213117.GS7074@brightrain.aerifal.cx> References: <20220502211856.GR7074@brightrain.aerifal.cx> <8735hr4ogc.fsf@oldenburg.str.redhat.com> <20220502213117.GS7074@brightrain.aerifal.cx> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] vfork()-based posix_spawn() has more failure modes than fork()-based one On 2022-05-03 00:31, Rich Felker wrote: > On Mon, May 02, 2022 at 11:25:07PM +0200, Florian Weimer wrote: >> * Rich Felker: >> >> > I'm trying to understand how this comes to be. The child should >> > inherit the namespaces of the parent and thus should not be in a >> > different namespace that precludes spawn. I'm guessing this is some >> > oddity where unshare doesn't affect the process itself, only its >> > children? If so, it seems like a bug that it doesn't affect the >> > process itself after execve (after unshare(1) runs your test program), >> > but that probably can't be fixed now on the Linux side for stability >> > reasons. :( >> >> It's about fundamentally conflicting requirements. >> >> The vDSO data mapping needs to store the time offset, so it has to be >> distinct from the original namespace. vfork preserves the VM sharing. >> It's not possible to do both things at the same time. >> >> unshare(CLONE_NEWTIME) should have been specified to only take effect >> after execve, when the vDSO is remapped anyway. > > Yes, exactly. The bug is that someone confused processes and process > images (fork and exec) when coming up with the constraint and now > we're probably stuck with it. *sigh* > Status update: the recently released kernel 6.2 contains the fix[1], so we're not stuck with this bug after all! [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b5f9dad32ed19e8db3b0f10a84aa824a219803b Alexey