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 28590 invoked from network); 2 May 2022 21:56:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 21:56:38 -0000 Received: (qmail 23776 invoked by uid 550); 2 May 2022 21:56:36 -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 23756 invoked from network); 2 May 2022 21:56:36 -0000 MIME-Version: 1.0 Date: Tue, 03 May 2022 00:56:24 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com Cc: Florian Weimer , Rich Felker , Andrei Vagin , Christian Brauner In-Reply-To: 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:49, Alexey Izbyshev wrote: > 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. > (Trying a different email for Andrei Vagin) > 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