Re: Proposal: getexecpath(3)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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

Yes, but for non-setid binaries it "doesn't matter".  If I can confuse
/bin/ls into doing something unusual, it doesn't matter, because I
could do that thing directly.  It's only binaries that run with more
privilege than their invoker that need to worry about this.

> [...], CGI binaries are good examples.  The environment is partially
> controllable by a "less-privileged" caller and can affect multiple
> users.

If you let Web clients specify exec path and argv[0] separately for CGI
binaries, and those CGI binaries depend somehow on being able to find
sibling files to their executables, with no better way to do that than
the exec path, then yes, you may have a problem.

...so, Don't Do That, Then.  Such programs are not suitable for CGI use
under such a webserver.  Such issues should IMO be laid at the doorstep
of whoever misconfigured the setup, not of the facility (mis)used.

> See, I would not like /rescue/cat to act as /rescue/rm, even if it is
> not setugid (:

No.  But being able to confuse /rescue/cat into running as if it were
/rescue/rm would not allow you to do anything you couldn't do anyway.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B