[Python-ideas] shutil.run (Was: shutil.runret and shutil.runout)

[Mike Meyer]

On Tue, 22 May 2012 18:39:16 +0300
anatoly techtonik <techtonik at gmail.com> wrote:

> Therefore, inspired by Fabric API, I've finally found the solution -
> shutil.run() function:
> https://bitbucket.org/techtonik/shutil-run/src
> 
> run(command, combine_stderr=True):
> 
>     Run command through a system shell, return output string with
>     additional properties:
> 
>         output.succeeded    - result of the operation True/False
>         output.return_code  - specific return code
>         output.stderr       - stderr contents if combine_stderr=False
> 
>      `combine_stderr` if set, makes stderr merged into output string,
>      otherwise it will be available  as `output.stderr` attribute.
[...]
> That's the most intuitive way I found so far. Objective advantages:
> 
> 1. Better than
>        subprocess.call(cmd, shell=true)
>        subprocess.check_call(cmd, shell=true)
>        subprocess.check_output(cmd, shell=True)
>      because it is just
>        shutil.run(cmd)
>      i.e. short, simple and _easy to remember_

-2

Unless there's some way to turn off shell processing (better yet, have
no shell processing be the default, and require that it be turned on),
it can't be used securely with tainted strings, so it should *not* be
used with tainted strings, which means it's pretty much useless in any
environment where security matters. With everything being networked,
there may no longer be any such environments.

> 3. shutil.run() is predictable and consistent - its arguments are not
> dependent on each other, their combination doesn't change the function
> behavior over and over requiring you iterate over the documentation
> and warnings again and again

As proposed, it certainly provides a predictable and consistent
vulnerability to code injection attacks.

> 4. shutil.run() is the correct next level API over subprocess base
> level. subprocess executes external process - that is its role, but
> automatic ability to execute external process inside another external
> process (shell) looks like a hack to me. Practical, but still a hack.

It's only correct if you are in an environment where you don't care
about security. If you care about security, you can't use it. If we're
going to add yet another system() replacement, let's at least try and
make it secure.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org