[contras1970]

so you install dstat in /usr/bin/dstat + /usr/share/dstat (because you are root), and an attacker creates /home/eve/bin/dstat with /home/eve/share/dstat/evil.py. why would you run /home/eve/bin/dstat? if eve can get you to run dstat from here ~/bin, why wouldn't she just have ~/bin/dstat with completely different contents?

i'm still convinced this is cargocult security.

[mehrdadn]

You're right that this wouldn't matter if the program is run with the same privileges as the caller. I was imagining if that wasn't the case (e.g. the user gives dstat setuid permissions), then letting it load arbitrary code could produce a security hole. Admittedly I didn't think too hard about whether/why something like this might be done -- if it wouldn't be, then never mind. As a matter of general safe practice I err on the side of caution, i.e. not depending on argv[0] to have any particular value for the correctness of the program, because otherwise you have to think through all the possible attack/error scenarios and likely document them for the user, etc... and I thought in any case it was worth pointing out that argv[0] did not necessarily correspond to the program location regardless.

[mehrdadn]

Edit/Update: You're right; I'm wrong -- I don't think this is the concern. Namely, I completely missed that the bug was already there in another line, and that the home directory was also being scanned. So it can't be a privilege escalation issue. Moreover I forgot that setuid doesn't work for scripts, so that shouldn't be the issue either. Not sure what's going on now either; I'm confused too.