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 27603 invoked from network); 2 May 2022 21:49:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 21:49:31 -0000 Received: (qmail 17900 invoked by uid 550); 2 May 2022 21:49:29 -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 17880 invoked from network); 2 May 2022 21:49:28 -0000 MIME-Version: 1.0 Date: Tue, 03 May 2022 00:49:16 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com Cc: Florian Weimer , Rich Felker , Andrei Vagin , Christian Brauner In-Reply-To: <5e002596-2450-98e0-f06b-39c458dcaf71@redhat.com> References: <20220502211856.GR7074@brightrain.aerifal.cx> <8735hr4ogc.fsf@oldenburg.str.redhat.com> <5e002596-2450-98e0-f06b-39c458dcaf71@redhat.com> 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, Carlos O'Donell wrote: > On 5/2/22 17:25, 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. > > Can we ask some kernel developers for an opinion? Christian Brauner had some comments [1,2] on this. Time namespaces were added in [3] by Andrei Vagin. Adding both to CC. Alexey [1] https://bugzilla.kernel.org/show_bug.cgi?id=215769#c6 [2] https://bugzilla.kernel.org/show_bug.cgi?id=215769#c10 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=769071ac9f20b6a447410c7eaa55d1a5233ef40c