PING: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

[David Lloyd]

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 <martinrb at 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.stuefe at 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.lloyd at 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.Riggs at 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.Riggs at 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