bug#22856: "make check" can start a shell on binary data

[Nick Bowler]

On 2016-02-29, Vincent Lefevre <address@hidden> wrote:
> When I cross-compile for Windows and run "make check" without
> LOG_COMPILER=wine (by mistake), strange files appear.
[...]
> ./tadd.exe: 1: ./tadd.exe: MZ address@hidden: not found
> ./tadd.exe: 2: ./tadd.exe: : not found
> ./tadd.exe: 1: ./tadd.exe: @.bss €: not found
> ./tadd.exe: 1: ./tadd.exe: .textd*,: not found
> ./tadd.exe: 3: ./tadd.exe: address@hidden: not found
[...]
> So, it appears that tadd.exe (which is a binary[*]) was executed
> by a shell!
[...]
> 10517 execve("./tadd.exe", ["./tadd.exe"], [/* 116 vars */]) = -1 ENOEXEC
> (Exec format error)
> 10517 execve("/bin/sh", ["/bin/sh", "./tadd.exe"], [/* 116 vars */]) = 0

Later on 2016-02-29, Vincent Lefevre <address@hidden> wrote:
> Sorry, forget this bug report. After wondering where the problem came
> from exactly, I've eventually found that this is some incredible bug
> in dash!

This crazy behaviour is actually permitted by POSIX, and to a certain
extent is even mandatory.  When executing a command whose name contains
a slash:

  "If the execl() function fails due to an error equivalent to the
  [ENOEXEC] error, the shell shall execute a command equivalent to
  having a shell invoked with the command name as its first operand,
  with any remaining arguments passed to the new shell.  If the
  executable file is not a text file, the shell may bypass this
  command execution."

(The text for commands without a slash is similar).

In POSIX text files are permitted to contain bytes with any value other
than 0 (NUL), so all sorts of line noise counts and is required to be
executed as a shell script.  But since the check is optional dash might
just not bother doing it, or maybe does not look at the entire file.

Cheers,
  Nick