From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14363 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tavian Barnes Newsgroups: gmane.linux.lib.musl.general Subject: Re: posix_spawn() can expose the error pipe to the spawned process Date: Mon, 8 Jul 2019 22:17:29 -0400 Message-ID: References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="52281"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14379-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 09 04:17:58 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 1hkfhc-000DTn-O3 for gllmg-musl@m.gmane.org; Tue, 09 Jul 2019 04:17:56 +0200 Original-Received: (qmail 3327 invoked by uid 550); 9 Jul 2019 02:17:54 -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 3293 invoked from network); 9 Jul 2019 02:17:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tavianator.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sbO1eLuivQvBEFsyArNTAwrC8/IwKIOQU+pFCak2kMw=; b=P0oLoVak25Pjr5+y3KXRP8mqdH3jHMxdqeZQ52LSJFmu9xbEaN8e5fk+0cgrOBjmk2 PLU4weGXpRYbBzixf+Uo5OGLqXfjcnslLx65LatxnDbCuN3nWLRksVw2syz0Tuq9OzEH 5DqRWNdqtGqu6R2HGBZc84oO27l7+k7ilfDeE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sbO1eLuivQvBEFsyArNTAwrC8/IwKIOQU+pFCak2kMw=; b=Bw65lEGVs6jChp/vvj/qMwW2gj99uoMWhTbYGuvZWRNrA6yP6txr4+BRmanELf2m3e T/8GkTqAYiBWKsfbvIsMw03dSXdHV0DicuauMTS/9yfBguupQ1blsCuMYfvprpby3bv0 QhgCyrC1LAFWQV53+4Eniwbodk/VZ0vCWh3wAZYESRmI13Tes0fcRMZwAu9iHnS3GVva Lpefbf2OnzmGwZDJ/97PlX0SCNCOgEgNGLug8LPBX0zjpxrHV1y/uxqD3ygBPGeQty/l 6CD5vWrSHdrN7KbOn2ZdSIsGtpB75ReyN3UB+ymzx7ujz1S/MpK37skLVJG1LJHv4Et0 Z+VA== X-Gm-Message-State: APjAAAVF3O5Oz6Aj1sCaRCpbL+/HwUTn/+o/o6/q1aMHDrdQYFEtKrmS GtfeWCU0x+6nOM4MPYzLuEgi3rHfdWYTzdUKG4dP2X4qcmQVNw== X-Google-Smtp-Source: APXvYqzoDxAAvNLS1BwiVc0KtwSwhy7Q8xWV34M9yK+ITb5vuH3fCfJ2s/tHO74piGysr0EuwedU0dl3QDByQMGXYV8= X-Received: by 2002:a65:56c1:: with SMTP id w1mr22994648pgs.395.1562638660821; Mon, 08 Jul 2019 19:17:40 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14363 Archived-At: [Sorry for messing up the threading, I'm not subscribed so I grabbed this from the archive] On Mon, 8 Jul 2019 at 13:09:55 -0400, Rich Felker wrote: > On Mon, Jul 08, 2019 at 11:39:49AM -0400, Tavian Barnes wrote: > > posix_spawn[p]() is implemented with a pipe that sends any error codes > > encountered back to the parent process. It attempts to move the pipe > > out of the way with dup() whenever that fd is used by the file_actions > > as an output, but not as an input. So something like this: > > > > $ cat spawn_pipe.c > > #include > > #include > > #include > > #include > > #include > > > > extern char **environ; > > > > int main() { > > posix_spawn_file_actions_t fa; > > posix_spawn_file_actions_init(&fa); > > posix_spawn_file_actions_adddup2(&fa, 4, 1); > > > > char *argv[] = { "printf", "\\5\\0\\0\\0", NULL }; > > > > pid_t pid; > > int ret = posix_spawnp(&pid, "printf", &fa, NULL, argv, environ); > > fprintf(stderr, "posix_spawnp(): %s\n", strerror(ret)); > > return ret; > > } > > $ musl-gcc -Wall spawn_pipe.c -o spawn_pipe && ./spawn_pipe > > posix_spawnp(): I/O error > > > > ends up writing to that pipe and causing posix_spawn() to report > > arbitrary errors. Presumably it should fail before exec()ing with > > EBADF instead. > > Thanks! To clarify, for anyone reading, the issue here is that you're > able to use a dup2 action in the spawn file actions to copy, and > thereby obtain the ability to send junk to, the pipe file descriptor > used internally. It's expected that the implementation can use file > descriptors internally, and that if you use/copy fds you don't own, > you could end up accessing one of them (this is the rationale for why > POSIX has no closeall operation). However it seems preferable to avoid > getting into an internally inconsistent state if this happens, and > that should be easy to do. Agreed. > Does the attached fix look ok to you? Yep, looks right. I was going to suggest moving the check next to the if (op->fd == p) check above, but it looks like op->srcfd isn't always initialized. > Note that there are still plenty of other ways you can do evil things > by copying internal fds, e.g. racing with another thread also calling > posix_spawn to copy its pipe fd, or anywhere else fds are used > (locale, message catalog, timezone, etc. loading, hosts/dns lookups, > ...). These are pretty much fundamental issues in using dup2 with a fd > you don't own. Yep, agreed. I don't think the current behaviour is a bug or non-standard-compliant or anything. Just seemed like an easy QoI improvement. > Rich