Re: Proposal: getexecpath(3)

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

On Sat, Jan 04, 2025 at 06:52:38AM +0000, Taylor R Campbell wrote:
 > The point here is to grant the callee access to the exec path
 > _without_ cooperation by the caller.
 > 
 > That way, the callee can find data files or libraries relative to
 > where it was found, without requiring the caller to pass paths to
 > those data files and libraries on the command line.
 > 
 > If the caller could be adapted to pass those paths, there would be no
 > need for any of this.

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.

It is reasonable to fail if the caller passes trash in argv[0].

The only cases where this isn't true are setugid bins, where argv[0]
might be malicious, and these cases shouldn't be using any of the
other referenced mechanisms either as most of them are subject to
races or other interference.

(IOW, I've never really understood the motivation for any of this
stuff.)

(Also, from a more forward-looking perspective, it is nice to not
compile in paths but probably an overall better scheme is to store
paths in executables in a way that allows updating them safely in the
field. But I don't think it's feasible to do this without moving on
from ELF.)

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