>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
