[Python-ideas] shutil.runret and shutil.runout

anatoly techtonik techtonik at gmail.com
Fri Feb 24 12:46:12 CET 2012

On Fri, Feb 24, 2012 at 2:25 PM, Mike Meyer <mwm at mired.org> wrote:
> On Fri, 24 Feb 2012 12:10:08 +0100
> Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> On Fri, Feb 24, 2012 at 11:52 AM, anatoly techtonik <techtonik at gmail.com>wrote:
>> > Hello,
>> > subprocess is low level, cryptic, does too much, with poor usability,
>> > i.e. "don't make me think" is not about it. I don't know about you,
>> > but I can hardly write any subprocess call without spending at least
>> > 5-10 meditating over the documentation. So, I propose two high level
>> > KISS functions for shell utils (shutil) module:
>> > runret(command)   - run command through shell, return ret code
>> mmm you are describing subprocess.call()  here... I don't see how this new
>> command makes thing better, besides shell=True.
> The stated purpose of the new functions is to allow people to run
> shell commands without thinking about them. That's a bad idea (isn't
> most programming without thinking about it?). The first problem is
> that it's a great way to add data injection vulnerabilities to your
> application. It's also a good way to introduce bugs in your
> application when asked to (for instance) process user-provided file
> names.
> -1

The proposal doesn't took into account security implications, so your
-1 is premature.

I agree with your point that users should think about *security* when
they run commands. But they should not think about how tons of
different ways to execute their command and different combinations on
different operating systems, *and* security implications about this.

This is *the main point* that make subprocess module a failure, and a
basis (main reason) of this proposal.

If users choose to trade security over simplicity, they should know
what the risks are, and what to do if they want to avoid them. So I
completely support the idea of shutil docs containing a user friendly
explanation of how to exploit and how to protect (i.e. use subprocess)
from the flaws provided by this method of execution - if they need to
protect. Python is not a Java - it should give users a choice of
simple API when they don't need security, and let this choice of
shooting themselves in the foot be explicit.. and simple.

anatoly t.

More information about the Python-ideas mailing list