From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14768 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: posix_spawn Date: Tue, 01 Oct 2019 09:05:18 +0200 Message-ID: <87pnjhvtch.fsf@oldenburg2.str.redhat.com> References: <20190930223632.GW9017@brightrain.aerifal.cx> <20191001022102.GA16318@brightrain.aerifal.cx> <20191001025543.GB16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="352"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Joshua Hudson , musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14784-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 01 09:05:37 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iFCE4-0018Bs-NL for gllmg-musl@m.gmane.org; Tue, 01 Oct 2019 09:05:36 +0200 Original-Received: (qmail 5474 invoked by uid 550); 1 Oct 2019 07:05:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5454 invoked from network); 1 Oct 2019 07:05:33 -0000 In-Reply-To: <20191001025543.GB16318@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 30 Sep 2019 22:55:43 -0400") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 01 Oct 2019 07:05:21 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:14768 Archived-At: * Rich Felker: > This is not safe and creates a false sense that something broken might > work. Moreover it's a vulnerability to use it this way. You have a > window where different tasks sharing VM space are executing with > different privilege levels, and thereby one is able to seize execution > of the other and achieve its privilege level. That's a non-sequitur. A shared address space does not necessarily mean that execution under one set of credentials will have unrestricted effects on executions under different credentials within the same address space. If the executions themselves are constrained, this can be completely safe. It is true that if there is one unconstrained execution in an address space, then the whole thing is tainted, but that this isn't the relevant scenario for things like file servers (which do not execute code on behalf of clients). I don't know where you got this idea, but it is wrong. I'm sorry.