https://www.unix.com/man-page/redhat/2/execve/ is from 1997.
On Wed, Jun 5, 2019 at 9:50 AM David Lloyd <david.ll...@redhat.com> wrote: > 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 > -- - DML
