Re: Proposal: getexecpath(3)

[David Holland <dholland-tech%netbsd.org@localhost>]

Since this thread's come back to life:

On Fri, Jan 10, 2025 at 03:09:02AM +0700, Robert Elz wrote:
 >   | 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.

Yeah, so you can lie to a program in argv[0] and maybe break it. You
can also send it SIGSEGV, or attach with ptrace and overwrite its
memory with deadbeef. What's your point?

The idea is to let third-party applications find their installed
resources without compiling in the install prefix, not to give setugid
programs new lengths of rope to hang themselves with.

Any getexecpath(3) should probably abort if issetugid().

-- 
David A. Holland
dholland%netbsd.org@localhost