On 12/10/24 1:31 PM, Michael Orlitzky wrote: > On 2024-12-10 00:54:11, Eli Schwartz wrote: >> >> What circumstances other than a shebang might break without a full path? > > When PATH is not reliable, like inside a cron job. Or arguments to execve().
execve doesn't make any sense to me as an argument. I don't think I've ever in my life either seen or heard of software that did a configure-time check for the full abspath of a file in order to solve the fact that execve doesn't search on PATH. They simply used execvpe instead. There may be other reasons for doing such a configure-time check, but "PATH is not reliable" is not one of them... Inside cron doesn't make a ton of sense to me either. A cron job will use a basic system PATH including these utilities already, and it frequently surprises people that the PATH set up in their ~/.bashrc isn't applied -- things like /opt/barware/bin and $HOME/.local/bin. Hardcoding the path to /bin/grep won't help in the slightest here, but hardcoding the path to a script installed in a non-default location would help. The script is then going to run with a basic PATH=/bin:/usr/bin and any core system utilities (such as grep, sed, dd) will be found but custom user scripts in the same directory as the configured crontab script will *not* be found. In both cases, there's nothing to gain from ensuring that autoconf sees full paths. For the execve case it's possible to write a proof of concept demonstrating the issue, but writing a PoC to demonstrate that people can write incorrect code doesn't prove that people *do* write incorrect code so the logic is circular. -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
