From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rich Felker Subject: Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2) Date: Fri, 9 Jan 2015 20:33:24 -0500 Message-ID: <20150110013324.GB4574@brightrain.aerifal.cx> References: <20150109161302.GQ4574@brightrain.aerifal.cx> <20150109204815.GR4574@brightrain.aerifal.cx> <20150109205626.GK22149@ZenIV.linux.org.uk> <20150109205926.GT4574@brightrain.aerifal.cx> <20150109210941.GL22149@ZenIV.linux.org.uk> <20150109212852.GU4574@brightrain.aerifal.cx> <87lhlbvbzs.fsf@x220.int.ebiederm.org> <20150109223843.GX4574@brightrain.aerifal.cx> <87mw5rtowa.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <87mw5rtowa.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Eric W. Biederman" Cc: Al Viro , David Drysdale , "Michael Kerrisk (man-pages)" , Andy Lutomirski , Meredydd Luff , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Andrew Morton , David Miller , Thomas Gleixner , Stephen Rothwell , Oleg Nesterov , Ingo Molnar , "H. Peter Anvin" , Kees Cook , Arnd Bergmann , Christoph Hellwig , X86 ML , linux-arch , Linux API , sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-arch.vger.kernel.org On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote: > Rich Felker writes: > > > I'm not proposing code because I'm a libc developer not a kernel > > developer. I know what's needed for userspace to provide a conforming > > fexecve to applications, not how to implement that on the kernel side, > > although I'm trying to provide constructive ideas. The hostility is > > really not necessary. > > Conforming to what? > > The open group fexecve says nothing about requiring a file descriptor > passed to fexecve to have O_CLOEXEC. It doesn't require it but it allows it, and in multithreaded programs that might run child processes (or library code that might be used in such situations), O_CLOEXEC is mandatory everywhere to avoid fd leaks. > Further looking at open group specification of exec it seems to indicate > the preferred way to handle this is for the kernel to return O_NOEXEC > and then libc gets to figure out how to run the shell script. Is that > the kind of ``conforming'' implementation you are looking for? This is a complex issue, and does not apply to native #! support (which is a supported executable format and thus not ENOEXEC) but rather standard POSIX shell scripts (which don't have a #! line at all). In this case the behavior of fexecve is perhaps under-specified. However, in cases where execve would succeed (without causing ENOEXEC), I think it's at least undesirable, if not non-conforming, for fexecve to fail. Should we request clarification from the Austin Group? Rich From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:36389 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752939AbbAJBe0 (ORCPT ); Fri, 9 Jan 2015 20:34:26 -0500 Date: Fri, 9 Jan 2015 20:33:24 -0500 From: Rich Felker Subject: Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2) Message-ID: <20150110013324.GB4574@brightrain.aerifal.cx> References: <20150109161302.GQ4574@brightrain.aerifal.cx> <20150109204815.GR4574@brightrain.aerifal.cx> <20150109205626.GK22149@ZenIV.linux.org.uk> <20150109205926.GT4574@brightrain.aerifal.cx> <20150109210941.GL22149@ZenIV.linux.org.uk> <20150109212852.GU4574@brightrain.aerifal.cx> <87lhlbvbzs.fsf@x220.int.ebiederm.org> <20150109223843.GX4574@brightrain.aerifal.cx> <87mw5rtowa.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mw5rtowa.fsf@x220.int.ebiederm.org> Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Eric W. Biederman" Cc: Al Viro , David Drysdale , "Michael Kerrisk (man-pages)" , Andy Lutomirski , Meredydd Luff , "linux-kernel@vger.kernel.org" , Andrew Morton , David Miller , Thomas Gleixner , Stephen Rothwell , Oleg Nesterov , Ingo Molnar , "H. Peter Anvin" , Kees Cook , Arnd Bergmann , Christoph Hellwig , X86 ML , linux-arch , Linux API , sparclinux@vger.kernel.org Message-ID: <20150110013324.abFcjEEpsiAXkl0Nla3P9hmg6DAltB8NwwA9adns124@z> On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote: > Rich Felker writes: > > > I'm not proposing code because I'm a libc developer not a kernel > > developer. I know what's needed for userspace to provide a conforming > > fexecve to applications, not how to implement that on the kernel side, > > although I'm trying to provide constructive ideas. The hostility is > > really not necessary. > > Conforming to what? > > The open group fexecve says nothing about requiring a file descriptor > passed to fexecve to have O_CLOEXEC. It doesn't require it but it allows it, and in multithreaded programs that might run child processes (or library code that might be used in such situations), O_CLOEXEC is mandatory everywhere to avoid fd leaks. > Further looking at open group specification of exec it seems to indicate > the preferred way to handle this is for the kernel to return O_NOEXEC > and then libc gets to figure out how to run the shell script. Is that > the kind of ``conforming'' implementation you are looking for? This is a complex issue, and does not apply to native #! support (which is a supported executable format and thus not ENOEXEC) but rather standard POSIX shell scripts (which don't have a #! line at all). In this case the behavior of fexecve is perhaps under-specified. However, in cases where execve would succeed (without causing ENOEXEC), I think it's at least undesirable, if not non-conforming, for fexecve to fail. Should we request clarification from the Austin Group? Rich