On Tue, May 22, 2012 at 11:30 PM, Mike Meyer <mwm@mired.org> wrote:

...

On Tue, 22 May 2012 18:39:16 +0300 anatoly techtonik <techtonik@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@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@MBP ~ $ mkdir foo && cd foo chris@MBP foo $ ls chris@MBP foo $ touch '~' # the horror chris@MBP foo $ touch '$EDITOR' # you have a sick mind chris@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@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.

On Tue, May 22, 2012 at 11:30 PM, Mike Meyer <mwm@mired.org> wrote:

...

On Tue, 22 May 2012 18:39:16 +0300 anatoly techtonik <techtonik@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@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@MBP ~ $ mkdir foo && cd foo chris@MBP foo $ ls chris@MBP foo $ touch '~' # the horror chris@MBP foo $ touch '$EDITOR' # you have a sick mind chris@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@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.