[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unfortunate error message for invalid executable

From: AA
Subject: Re: Unfortunate error message for invalid executable
Date: Sun, 29 May 2022 07:54:36 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

(I originally overlooked your mention of a race)

... by the way, I'm curious whether bash is systematically coded to defend against these kinds of races and whether they are in fact a material concern?

Notwithstanding, in this particular case, we're talking only about generating an error message based on the results of a two step procedure if fexecve() is missing where *that* error text could hedge against the possibility of a race by including the word "may."

The horse is almost dead.


On 5/29/22 7:11 AM, Andrew Athan wrote:
Awesome (I made no claims of expertise about the details of the call semantics). I agree any multi-call scenario would among other things not be atomic. Though, I’m not sure that’s what you mean by hoodwinked.

That last suggestion is exactly one I also made (simply improve the error text) and I completely agree would suffice if there isn’t a technical solution to disambiguate the actual error condition.

My nezt step was going to be to find the source, and check where the string is generated or looked ip.


On May 29, 2022, at 4:34 AM, Martin D Kealey <martin@kurahaupo.gen.nz> wrote:

On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again SHell, <bug-bash@gnu.org> wrote:

    Maybe the concern is that any additional calls (such as checking
    for path existence) may have unintended consequences [but that]
    seems unlikely.

    Therefore, IMHO it is very hard to argue with the fact that the
    file passed to the kernel does in fact exist

Actually it's quite easy to argue with that: a race condition between when execve fails and when we subsequently check whether the file exists means we could be hoodwinked into reporting the wrong error message in both directions.

Either use fexecve (where it exists) to be CERTAIN that the file exists before invoking it, or simply adjust the wording of the error message to make the ambiguity clear.

Then again, "file (or its interpreter) does not exist" would cover both cases without needing to check separately whether the file exists.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]