Re: Proposal: getexecpath(3)

["Jean-Yves Migeon (NetBSD)" <jym%helkyn.org@localhost>]

Le 06/01/2025 à 03:24, David Holland a écrit :
> On Sun, Jan 05, 2025 at 04:24:23AM +0100, Jean-Yves Migeon (NetBSD) wrote:
>   > argv[0] (by C99) is just program's name, and has no warranty of
>   > representing (even a substring of) the exec path; and has its use in that
>   > regard, e.g. crunchgen(1). Reliably deducing the exec path from argv[0] is
>   > tricky. getexecpath(3) would have no ambiguity on its semantic.
>
> We're not talking about C99, or the provisions in C99 for MS-DOS and
> Windows; we're talking about Unix and specifically NetBSD. I think you
> missed the part where I wrote:
>
>   > > This is a matter of the conventions of shells
>
> For the sake of argument, I wrote the code, stuck it in /usr/local/bin,
> and ran it in various ways, first from sh:

This is not a shell matter.

POSIX (.1 if you prefer) says that argv[0] contains a filename string, 
with a rationale that is ambivalent on filename/path/exec name, and says 
nowhere that it shall be a pathname (or a substring of) to the execution 
file [1] . You cannot ensure more than that. It even gives the example 
of "-".

There is a huge outside world that cares little about NetBSD's 
expectations or "conventions" (sadly). The purpose is to avoid 
cooperation of the caller -- which is what a shell is actually doing.

Give the same experiment a try with C and an "uncooperative" caller, and 
explain how you are supposed to "fix" the C code to cope and find the 
exec path? Which obviously is needed, considering the numbers of 
projects that end up parsing /proc/pid/exe or KERN_PROC_PATHNAME.

$ cat hey.c
#include <stdio.h>

int main(int argc, char **argv)
{
	printf("%s\n", argv[0]);
	return 0;
}
$ cc -o hey hey.c
$ python3.11
[...]
> import os
> os.execve("/wherever/you/want/hey", ["hoh"], {})
hoh

> [snip]
> Likewise you could certainly start qemu or some other program that
> wants to use this technique to get its install prefix, and
> intentionally lie to it so it doesn't run or crashes trying to find
> its initialization files. But what's the point? And again, you can do
> this with all the proposed techniques.
>
> The question is whether it works as expected under normal conditions,
> and it does.

Make a difference between expectations and specifications. Your 
assumptions are not necessarily the ones made by others. That proposal 
is unambiguous from a semantic standpoint. All other approaches that 
involve PATH/proc/sysctl arts are fragile and error-prone.

[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/exec.html

--
jym@