4 ms·

That "solution" won't protect you from this. All you're doing is hiding the call to system/execve behind deeper layers of abstraction. Plus if people actually

That "solution" won't protect you from this. All you're doing is hiding the call to system/execve behind deeper layers of abstraction. Plus if people actually went ahead and reproduced all of the GNU/busybox toolchain inside of Python then everyone would be queuing up to criticise them, particularly if they introduced more security issues (e.g. reproducing rsync fully within a Python library). Realistically using execve instead of system is a step forward. It is more efficient for non-scripts and you aren't potentially picking up poisoned environmental variables. But if you NEED to run utilities then all you can really do is pre-parse all the parameters carefully and hope for the best. Suggesting never using either execve or system is just highly unrealistic. There is just too much useful code available via it and aren't nearly enough libraries to reproduce all of that code within whatever language you're working.

antocv 12y ago
> All you're doing is hiding the call to system/execve behind deeper layers of abstraction. Thats the point, layers where environment variables do not pass - since they in that abstraction do not make sense. > Plus if people actually went ahead and reproduced all of the GNU/busybox toolchain inside of Python Basically all of gnu coreutils/busybox, is already inside python, its called import os. For your rsync example, python-librsync exists. C library, with python binding/interface. No need to run a bash to use the algorithm. If you still want to exec it, then use pythons binding to exceve system call or similar, not to system. I didnt suggest never to use execve and/or system, I said do not ever use system, sometimes highly questionably use execve.