Re: Proposal: getexecpath(3)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 18 Dec 2024 19:26:50 +0100
> From: "Jean-Yves Migeon (NetBSD)" <jym%helkyn.org@localhost>
> 
> I welcome such an addition; I had to deal with a problem alike in a 
> "portable" way (...), and that ended up in a painful and fragile way. I 
> have some remarks though, low tier (not blocking/critical).

> 1 - As there is prior art elsewhere (getexecname(3)), unless there is a 
> specific (legal?) reason not to have the same name, I would reuse it (or 
> provide an alias) -- especially when obscure autotooling are looking for 
> such a function;

We could adopt the name `getexecname' from Sun.  The reason I didn't
do this is that Solaris (or at least, illumos) has somewhat quirky
semantics about partial normalization.  The semantics I'm suggesting
instead is extremely simple and reliably predictable: the path
argument to execve(2) is passed through verbatim.

On the other hand, we already implement AT_SUN_EXECNAME with different
semantics from Solaris (our own quirky partial normalization) -- but
then that's not really a public interface, so it's not as risky to
break the `new semantics, new name' rule.

I'm willing to adopt the Sun name if there's consensus on it -- I'm
just not convinced that Sun's partial normalization semantics is
reasonable, and I'm leery of breaking the `new semantics, new name'
rule for public-facing interfaces like this.

> 2 - some shells like ksh(1) add the "_" environ parameter, and I have 
> never seen or heard programs behaving badly because of it. So there is 
> also prior art here -- but that implies a cooperative execve(2) caller, 
> which is not quite in the present scope. I always wondered whether some 
> programs used that functionality, but never encountered one (probable 
> blindness here). Obviously this moves out the functionality from auxv to 
> envp;

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.

> 3 - (at least for Linux) /proc/self/file is shown as a symlink, but it 
> is not really one. When the pointed file is removed (or disappeared, 
> inaccessible, whatever), AFAIR we get something like "(removed/deleted)" 
> appended; I expect a symlink to remain as-is. I understand the reason 
> behind that choice, but it shows the limitations of such an approach, 
> and how fragile this can become. I became wary of using readlink(2) 
> results bluntly around /proc and /sys.

Yes, this interface is pretty weird.