If we're talking just Linux though, has this *ever* been an issue? You've been able to call execve on a shell script since at least 2002 as far as I can tell from a quick search. Maybe this should be conditional so that it can be excluded on known-good platforms?
On Wed, Jun 5, 2019 at 9:40 AM Martin Buchholz <marti...@google.com> wrote: > https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html > > """Historically, there have been two ways that implementations can exec > shell scripts. > > One common historical implementation is that the execl(), execv(), > execle(), and execve() functions return an [ENOEXEC] error for any file not > recognizable as executable, including a shell script. When the execlp() and > execvp() functions encounter such a file, they assume the file to be a > shell script and invoke a known command interpreter to interpret such > files. This is now required by POSIX.1-2017. These implementations of > execvp() and execlp() only give the [ENOEXEC] error in the rare case of a > problem with the command interpreter's executable file. Because of these > implementations, the [ENOEXEC] error is not mentioned for execlp() or > execvp(), although implementations can still give it. > > Another way that some historical implementations handle shell scripts is > by recognizing the first two bytes of the file as the character string "#!" > and using the remainder of the first line of the file as the name of the > command interpreter to execute. > """ > > On Tue, Jun 4, 2019 at 11:54 PM Thomas Stüfe <thomas.stu...@gmail.com> > wrote: > >> Hi David, >> >> You are right. I am pretty sure there are ancient historical reasons for >> doing this by hand instead of letting exec() deal with scripts itself. >> Martin or Roger may know more. >> >> But I think right now this is more of a compatibility concern - changing >> this behavior has the risk of breaking lots of user code. Since we have not >> the manpower to deal with this - look at how long simple fixes are in >> review, we are all busy elsewhere - chances of changing this are small. >> >> Cheers, Thomas >> >> >> On Tue, Jun 4, 2019 at 10:14 PM David Lloyd <david.ll...@redhat.com> >> wrote: >> >>> In this case, going from what the execve(2) Linux man page says (and Mac >>> seems to agree), if the script were executable it would have a '#!' >>> interpreter string and the kernel would execute it anyway, would it not? >>> What case would be solved by explicitly starting a shell? >>> >>> On Tue, Jun 4, 2019 at 2:15 PM Roger Riggs <roger.ri...@oracle.com> >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> If the argument is not an .exe, then it may be a command shell script >>>> (.sh, etc.) >>>> Only the system knows it is not an exe (errno == ENOEXEC), so it then >>>> passes it as >>>> the first argument to /bin/sh that will handle the shell files. >>>> >>>> And yes, count me as a Reviewer and reviewed. >>>> >>>> Roger >>>> >>>> On 06/04/2019 12:14 PM, Thomas Stüfe wrote: >>>> >>>> On Tue, Jun 4, 2019 at 5:09 PM Roger Riggs <roger.ri...@oracle.com> >>>> wrote: >>>> >>>> ... >>>> >>>> >>>> Then I ran an strace over it and saw this: >>>> >>>> 5332 [pid 3911] execve("./sleep2", ["./sleep2"], [/* 78 vars */] >>>> <unfinished ...> >>>> .. >>>> 5342 [pid 3911] <... execve resumed> ) = -1 ENOEXEC (Exec format >>>> error) >>>> 5343 [pid 3911] execve("/bin/sh", ["/bin/sh", "./sleep2"], [/* 78 vars >>>> */] <unfinished ...> >>>> 5347 [pid 3911] <... execve resumed> ) = 0 >>>> >>>> So, if the first exec fails for whatever reason, we try again, passing >>>> the executable file name as argument to the system shell. This does not >>>> feel right? Do you know why we do this? >>>> >>>> >>>>> >>>>> Thanks, Roger >>>>> >>>>> >>>> Thank you Roger. Can I consider the patch to be reviewed by you? >>>> >>>> ..Thomas >>>> >>>> >>>> >>> >>> -- >>> - DML >>> >> -- - DML
