Re: Proposal: getexecpath(3)

[<tlaronde%kergis.com@localhost>]

On Mon, Jan 06, 2025 at 02:24:35AM +0000, David Holland wrote:
> On Sun, Jan 05, 2025 at 04:24:23AM +0100, Jean-Yves Migeon (NetBSD) wrote:
>  > > Under normal circumstances the callee can use argv[0], though
>  > > admittedly it's a bit of a nuisance since it requires examining $PATH
>  > > if there's no / in the string. One could certainly make a library
>  > > function that does that though.
>  > 
>  > 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:
> 
> $ hey
> my path: /usr/local/bin/hey
> $ /usr/local/bin/hey
> my path: /usr/local/bin/hey
> $ PATH=.:$PATH hey
> my path: /usr/local/bin/hey
> $ (cd /usr/local/bin && PATH=.:$PATH hey)
> my path: ./hey
> $ (cd /usr/local/bin && PATH=$PATH:. hey)
> my path: /usr/local/bin/hey
> $ (cd /usr/local/bin && PATH=. hey)
> my path: ./hey
> $ (cd /usr/local/bin && PATH= hey)
> my path: ./hey
> $ (cd /usr/bin && PATH= hey)
> sh: hey: not found
> 
> which is correct in all cases. Then I ran the same cases again from
> ksh, bash, zsh, csh, and tcsh, all of which gave the same results.
> 
> This should not come as a surprise; shells work this way by
> long-standing convention.

This is POSIX.2 defined behavior. But hence the questions:

1) Does NetBSD impose that any process should be expecting exact POSIX (here POSIX.2)
behavior, and that using a not POSIX compliant shell or a not POSIX
compliant application is a fault leading to errors (UB)?

2) The behavior depends on the definition of PATH. Hence the problem
of atomicity: searching the PATH, afterwards, is not guaranteed to
yield the same result because of any posterior modification, whether in the
filesystems or in the very definition of PATH.

So, for me, the facility can only be at any use if the answer is fixed
at exec time with the path actually used (but, if security is
involved, a mean---checksum?---should be added to verify that the
registered path leads to the very program; but, if the program is
needed, since it is a process in memory, the safer way is to fork, not
to go back to some shell and rely on the path...).

So it seems, from the discussion, that it is a facility that needs
to be added because some (external) programs use it; but its use
should not be encouraged---too many holes.

-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C