From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 98D823858D37 for ; Fri, 28 Jan 2022 18:03:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98D823858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: fTyDv0Ao5G4WlXL7FyiJ/ZRMDutwl10X2LcgjIMI8mW6q3c4hDzi9RSoFW2Nseoyvf94w/dY8P ODw03F8vDJaqyY45+xdy00zEdD6uKjrCTereB7MtQPyMAjsBjUL3IkI9BkOz5TOxTuVG0aC1o1 EX0x9FYbwQG0KZAnhnYb1M4Fgm7Sijxa6yhxCBuoSz+4/GMmScAPuXvpXbUmX3CzpdXcsiV8bQ KLzsiF26NTpQmSDXBrd2YuJ2ODeR51rYs8mZXqPwfA8dVYe1SA7XQ3lo3Ar3f8s8iTxlwAVa0N EUQDCbh//mBBUf+w73ko0g9C X-IronPort-AV: E=Sophos;i="5.88,324,1635235200"; d="scan'208";a="71303191" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 28 Jan 2022 10:03:51 -0800 IronPort-SDR: m7yueRZaHUT4Dw5oY8JM8fzxgvIQZwQKuXmt94I5iVEFfVvLaT5MxeBeeQFpe7O6pKHLTYenn2 WAFJoKaV0NzKjuPtJOxjOkTpm80ID7sJ8OUcFxhpMSFqBYIYzWUsfZNeq0O1iyxoDqexJfMu/E RdDLf3YyBR/+uDyxSVZ9+N/KGwrIN1vvb8EXlRgvxilxKs0Ln/xhzZ96Wp2ouIPTUvDQDP9KTD dyGn2Ivaivld/mmmbVHQR43aIQDHeg9mVialu7atTS1IZVR89glWGLxdV0+jULh0exKMB27kgz StU= Date: Fri, 28 Jan 2022 18:03:46 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Adhemerval Zanella CC: =?ISO-8859-15?Q?Cristian_Rodr=EDguez?= , Subject: Re: [PATCH 2/2] linux: posix_spawn: return EINVAL on argc < 1 In-Reply-To: Message-ID: References: <20220128133937.9555-1-crrodriguez@opensuse.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3114.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 18:03:53 -0000 On Fri, 28 Jan 2022, Adhemerval Zanella via Libc-alpha wrote: > Since Linux is discussing changing on execve syscall [1], I think it would be > better to the same not only for posix_spawn, but rather to all execve > functions. > > And since all ends up calling execve, even posix_spawn, I think it would be > better to: > > 1. Make posix/execve.c call __execveat. > 1.1. It would also allow remove the Hurd implementation 'sysdeps/mach/hurd/execve.c' > 2. Add the proper check on generic, Linux, and Hurd implementation execveat. > 2.1. Maybe even add __execveat_internal that just issue the syscall and let the > generic wrapper handle the argument parsing. > 3. Add a regression test. > > I also think returning EINVAL is better than the kernel EFAULT one (it > seems that the last message on thread does settle for that). Apart from the need for a test, a note under "Deprecated and removed features, and other changes affecting compatibility" in NEWS, and documentation in the manual if there's an appropriate place for it to go (there is for execve; posix_spawn isn't documented in the manual at all), I'd also think it would be better in terms of application compatibility to construct an array { pathname, NULL } and pass that in place of argv when argv[0] is NULL (*not* when argv[0] is an empty string, I don't see a problem with an empty string there), rather than returning an error. That's more similar in spirit to what we do with reopening fds 0, 1, 2 if not open at startup (but I'd also tend to think the kernel is a better place than libc to deal with this, given that anything the *calling* program does in userspace with execve can't avoid security issues in the *called* program with NULL argv[0] - in the case of fds 0, 1, 2 glibc is addressing the problem state directly in the *called* process). I don't think the "should" in the POSIX specification of posix_spawn is very relevant as a justification for the patch (it only requires things for Strictly Conforming POSIX Applications). -- Joseph S. Myers joseph@codesourcery.com