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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25112 invoked from network); 2 May 2022 21:31:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 21:31:33 -0000 Received: (qmail 4075 invoked by uid 550); 2 May 2022 21:31:31 -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 4054 invoked from network); 2 May 2022 21:31:31 -0000 Date: Mon, 2 May 2022 17:31:18 -0400 From: Rich Felker To: Florian Weimer Cc: Alexey Izbyshev , musl@lists.openwall.com Message-ID: <20220502213117.GS7074@brightrain.aerifal.cx> References: <20220502211856.GR7074@brightrain.aerifal.cx> <8735hr4ogc.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8735hr4ogc.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] vfork()-based posix_spawn() has more failure modes than fork()-based one 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* Rich