Re: Proposal: getexecpath(3)

Le 04/01/2025 à 11:22, David Holland a écrit :
> 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.

Also all argv[] strings can be modifiable by callee. pathname of the 
execution (as passed to execve(2) or like) is not.

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

I agree as long as it is gracefully done. *argv contains 
implementation-defined values. So would be its failure modes when 
dealing with garbage.

> 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.

Pretty much "any" binary, not just setugid.

Any binary that is subject to confused deputy problem can be. If you 
consider the "traditional" user's security boundary, CGI binaries are 
good examples. The environment is partially controllable by a 
"less-privileged" caller and can affect multiple users.

Now TBH even a "standard" program that fails miserably argv handling and 
wreaks havoc as a normal user would still be very painful. See, I would 
not like /rescue/cat to act as /rescue/rm, even if it is not setugid (:

-- 
jym@