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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	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 24322 invoked from network); 2 May 2022 21:25:27 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 2 May 2022 21:25:27 -0000
Received: (qmail 32113 invoked by uid 550); 2 May 2022 21:25:25 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 32092 invoked from network); 2 May 2022 21:25:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1651526713;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=gIdVSwoWpLThoKskPDZl0iZ3WpmvFphxCwnahvGwExo=;
	b=ECdmpDopoUtRywVj+k1zKBi1nGxRDDbSxccEilFNF2mJkJjLk/NpHoU1UqVRLxvLX1tfKx
	1BpPD6OyaPTW8mSUPu3mO73NGTrExMwFt8iUdUl0NfRLPmLfywCRFohQ1Pn2aiwNGYH/cA
	lOxhc2024YYwHsraTyq1RJ64xUd+908=
X-MC-Unique: 6lAWCleON1ynOkqYCTPfGA-1
From: Florian Weimer <fweimer@redhat.com>
To: Rich Felker <dalias@libc.org>
Cc: Alexey Izbyshev <izbyshev@ispras.ru>,  musl@lists.openwall.com
References: <e7dc11a5db39ecb427f02d9a6db3971d@ispras.ru>
	<20220502211856.GR7074@brightrain.aerifal.cx>
Date: Mon, 02 May 2022 23:25:07 +0200
In-Reply-To: <20220502211856.GR7074@brightrain.aerifal.cx> (Rich Felker's
	message of "Mon, 2 May 2022 17:18:56 -0400")
Message-ID: <8735hr4ogc.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Subject: Re: [musl] vfork()-based posix_spawn() has more failure modes than
 fork()-based one

* 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.

Thanks,
Florian