Re: Misleading error when attempting to run foreign executable

[Ángel]

On 2021-10-12 at 00:48 +0700, Robert Elz wrote:
>   | When execve returns this error for what is a clearly invalid
> reason,
> 
> The problem is that sometimes it will probably be an invalid reason
> (that's where the race conditions can matter, that the file was there
> when it was checked doesn't mean it is still there now, so the reason
> might be valid, and I'm not sure it is really worth another stat() to
> find out - and even if the stat() is done and that says the file
> exists,

Note I did NOT add a stat() call. It was already there in bash, *after*
execve() fails (so it can do a manual script run, etc.). I only changed
the error message it outputs in this case.

> the exec attempt might just have happened in the middle of a
>          mv a a.old; mv a.new a
> sequence).

Sure, that could happen.¹ Still, I think the error message saying that
execve() failed but the program exists is not that misguided. And, more
importantly, fixes the general issue of the misleading "No such file or
directory" for files requesting an ELF interpreter which is not
available in the current system.

If this race condition was such a big deal, then we should also be
concerned about a program being replaced with a directory. Or a shell
script with a binary file once it decides it can be executed as a
script.

If someone changes the binary between execve() time and when bash
examines it (as it already does), the diagnostic can be wrong. But
that's still no worse than the alternative of letting the user inspect
it manually.


Best regards



¹ And the obvious solution if it is expected a can be run at any point
would have been to instead do: ln a a.old; mv a.new a