Re: Undelivered Mail Returned to Sender

[Zack Weinberg <zackw@panix.com>]

 I have no idea why my mail glitched like that.  Sorry for the inconvenience.

On Tue, Dec 15, 2020 at 5:42 PM Carlos O'Donell <carlos@redhat.com> wrote:
>On 12/15/20 4:04 PM, Zack Weinberg wrote:
>> On Tue, Dec 15, 2020 at 3:46 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>>> On 12/15/20 8:05 AM, Zack Weinberg wrote:
>>>> When direct execution of a program fails with ENOEXEC, do not attempt
>>>> to run that program as if it were a shell script.
>>>
>>> A less-intrusive approach would be for execlp etc.'s fallback to look at the
>>> first 1024 bytes (or whatever) of the file and fail with ENOEXEC if it finds
>>> a NUL byte, before trying to exec /bin/sh on the file.
>>
>> That's a clever idea for preserving compatibility, but to do it we
>> would have to open and read the file, which could easily cause
>> problems due to e.g. lack of free file descriptor space.  If we can't
>> remove this code altogether I'm not sure it's worth changing anything
>> in libc.
>>
>> POSIX recommends that the *shell* implement a similar heuristic, and
>> it appears bash already does.
>
>What shell were you using that didn't implement this?

dash doesn't, and neither does zsh --

$ bash /bin/ls; echo $?
/bin/ls: /bin/ls: cannot execute binary file
126

$ dash /bin/ls; echo $?
/bin/ls: 1: Syntax error: ")" unexpected
2

$ zsh /bin/ls; echo $?
/bin/ls:1: parse error near ')'

Also, it's pretty easy to subvert bash's heuristic:

$ dd if=/dev/urandom count=1 | tr -d '\0' > test.x
$ bash test.x
test.x: line 4: syntax error near unexpected token
`$'\333\313\353D\341\252\341N\330\313\342\a\202g\027\225\276kE!\332\315D\226/M\2669\222''

zw