(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
<mar...@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.
-Martin
