[Python-ideas] shutil.run no security thread

[Chris Rebert]

> On Tue, May 22, 2012 at 11:30 PM, Mike Meyer <mwm at mired.org> wrote:
>> 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
<snip>
>> -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
<snip>
>> 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.

On Wed, May 23, 2012 at 1:47 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> Ok, let's separately discuss shutil.run() added value without touching
> security at all (subj changed).
>
> Is it ok? Is it nice idea? Would it be included in stdlib in an ideal
> world where security implications doesn't matter?

I hope not, because it'd still have all the /usability/ pitfalls
associated with shell interpolation (and the consequent need to escape
command arguments).

Consider:
chris at MBP ~ $ mkdir foo && cd foo
chris at MBP foo $ ls
chris at MBP foo $ touch '~'  # the horror
chris at MBP foo $ touch '$EDITOR'  # you have a sick mind
chris at MBP foo $ ls -l  # verify the devious plot
total 0
-rw-r--r--  1 chris  staff  0 May 23 02:11 $EDITOR
-rw-r--r--  1 chris  staff  0 May 23 02:11 ~
chris at MBP foo $ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
>>> from os import listdir
>>> from subprocess import call
>>> for entry in listdir('.'):
…     ret = call('ls '+entry, shell=True) # à la your wrapper
...
ls: ed: No such file or directory
<snipped; the contents of my home directory was here>
>>> # that's not what I wanted at all!

(Less contrived examples left as an exercise for the reader.)

Also, this isn't shell-specific, but it still should be made easier to
handle properly: What about a file named "--help"?

Cheers,
Chris
--
Sadly, no, `ed` isn't really my editor.
http://rebertia.com

P.S. Please avoid top-posting in the future.