Re: Unfortunate error message for invalid executable
On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again SHell, 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. -Martin
Re: Unfortunate error message for invalid executable
(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. A. 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. A. On May 29, 2022, at 4:34 AM, Martin D Kealey wrote: On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again SHell, 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. -Martin
Re: Unfortunate error message for invalid executable
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. A. > On May 29, 2022, at 4:34 AM, Martin D Kealey wrote: > > > > >> On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again >> SHell, 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. > > -Martin
