Re: Proposal: getexecpath(3)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 9 Jan 2025 13:52:01 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <Z3_UgWdVDwJu5cNf%netbsd.org@localhost>

  | It absolutely is. argv[0] is provided by the program that calls
  | execve, which for ordinary 3rd-party application software that wants
  | this feature is either the shell or a shell substitute (such as a
  | window manager, desktop start button, etc.)
  |
  | There is no reason to care about what an "uncooperative" caller does.

Sorry, but this is nonsense.

No application can know (without getppid() and either /proc or parsing
ps output) what application it was started from.   And it is entirely
reasonable to make applications whose whole purpose is to run another
program with something different than the program name as argv[0] - I
used to do that all the time when testing login shells, actually logging
in every time is way too much effort, but a program that would exec
the test binary I was using, but make its argv[0] simply be "-sh" (whatever
the test shell version binary was called, or what the path to it was) was
about 20 seconds of code writing.

Further, if you're not using our /bin/sh then there's an even easier
way, many shells have a -a option to "exec" with the whole purpose of
allowing argv[0] to be set to any desired value)

Given /tmp/dummy.c containing:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int
main(int argc, char **argv)
{
        printf("%s\n", *argv);
        return 0;
}

(all 3 includes are probably not required, just my standard set
for simple test programs like this).   Compile it to make /tmp/dummy
then running it as just "/tmp/dummy" will produce "/tmp/dummy" on
stdout.   Running it as "(exec -a foobar /tmp/dummy)" from a shell
which supports that (bash mksh ksh93 yash bosh zsh .. maybe more)
and it will print "foobar".

  | Furthermore, as I've already pointed out a couple times, a hostile
  | caller can confuse any of these schemes.

They can, which is perhaps why this getexecpath() request was made.

  |    % mkdir /tmp/confusion /tmp/confusion/bin
[you probably omitted a cd here]
  |    % ln /usr/pkg/bin/qemu .
  |    % ./qemu
  |
  | Then the path to the executable _is_ /tmp/confusion/bin, and you're
  | done.

Yes, and if something wanted to use argv[0] to find other data, or
other related binaries, then unless they're also installed (in the new
location), then things will fail - just as they would if qemu (in this
example) were left in its normal place, but the other data/binaries were
never installed (or later removed).   Nothing exciting about that.

I suspect that what is wanted is for a properly installed qemu
to be able to run (without any of the above setup) as
	(exec -a /tmp/confusion/bin/qemu /usr/pkg/bin/qemu [....])
and have it still work (though programs which use what is argv[0]
to determine what they should do, eg stat & readlink, amongst others,
will only work if at least the last element of the path in argv[0] is
something which will elicit the intended behaviour).

  | You can't do it that way if /usr/pkg isn't on the same volume as /tmp,

You mean changing "ln" to "cp" is somehow difficult ?   (or even ln -s)

I have no opinion on whether there's enough real need for a getexecpath()
interface to exist or not, but arguing that argv[0] already provides the
same information is simply wrong.

kre

ps: I know /tmp/dummy as above isn't perfect, it should test that *argv
is not NULL before blindly printing it ... there's no absolute guarantee
that it won't be.