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

[Nick Coghlan]

On Fri, Feb 24, 2012 at 10:59 PM, Mike Meyer <mwm at mired.org> wrote:
> That's a backwards approach to security. Rather than allowing anything
> and turning off what you know isn't safe, you should disallow
> everything and turn on what you know is safe. So rather than trying to
> make the strings you pass to the shell safe, you should parse them
> yourself and avoid calling the shell at all.

Yes, that's why these are *separate functions* (each with "shell" in
the name to make the shell's involvement rather hard to miss). Any
application (rather than system administration script) that calls them
with user provided data should immediately fail a security audit.

The new APIs are intended specifically for system administrators that
want the *system shell*, not a language level "cross platform"
reinvention of it (and when it comes to shells, "cross platform"
generally means, "POSIX even if you're on Windows, because we're not
interesting in trying to reproduce Microsoft's idiosyncratic way of
doing things"). The automatic quoting feature is mainly there to
handle spaces in filenames - providing poorly structured programs with
some minimal defence against shell injections is really just a bonus
(although I admit I wasn't thinking about it that way when I wrote the
current docs).

As things stand, Python is a lousy language for system administration
tasks - the standard APIs are either *very* low level (os.system()) or
they're written almost entirely from the point of view of an
application programmer (subprocess). Even when I *am* the
administrator writing automation scripts for my own use, the
subprocess library still keeps getting in the way, telling me it isn't
safe to access my own shell.

Normally, Python is pretty good about striking a sensible balance
between "safe defaults" and "consenting adults", but it currently
fails badly on this particular point.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia