Date: Sun, 11 Apr 2021 14:02:15 +0200
From: "Joerg Schilling via austin-group-l at The Open Group"
<[email protected]>
Message-ID: <20210411120215.wchk4%[email protected]>
| If command -v should become able to do more, we would need to invent a
| way to execute _any_ utility (regardless of whether it is a binary or
| script) to execute in a harmless way without side-effects.
The way to do that would be to add an exectest*() set of system calls to the
exec*() family (one for each of the exec*() calls) which does exactly the same
thing as the exec*() system calls, up to the point where the kernel has
decided that it is going to run the binary, and is just about to destroy
the current image and replace it with a new one. Instead of doing that,
the exectest*() system calls would simply return 0. If any error was
detected before that point, then the error return would be identical to
that from exec*(). Almost no code would be needed to make this work,
aside from libc sys call stubs, and lots of documentation.
I was going to have just one new sys call (and in the implementation,
rather than libc, there might just be one, or two perhaps, required in
any case) with just the path name to test as the arg, which is all that
would be needed, or used, by command -v, but other applications might want
to determine whether they can exec a combination of binary+args+env
(not get E2BIG from too many args, etc) so, if something new were to
be invented, it should start out being truly useful, not just half.
Personally, I think the actual problem here is more noise ("what would
happen if ...?") type thing than any real world problem, so I'm not
about to waste cycles attempting to fix something that doesn't really
need fixing, other than to assuage someone's "that's weird" feeling.
kre
