[Python-ideas] Security: remove "." from sys.path?

[Nick Coghlan]

On 4 June 2017 at 10:00, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Is this really much of a security issue? Seems to me that
> for someone to exploit it, they would have to inject a
> malicious .py file alongside one of my script files. If
> they can do that, they can probably do all kinds of bad
> things directly.

There are genuine problems with it, which is why we have the -I switch
to enable "isolated mode" (where pretty much all per-user settings get
ignored). However, just dropping the current directory from sys.path
without also disabling those other features (like user site-packages
processing and environment variable processing) really doesn't buy you
much.

So the better answer from a security perspective is PEP 432 and the
separate system-python binary (and Eric Snow recently got us started
down that path by merging the initial aspects of that PEP as a private
development API, so we can adopt the new settings management
architecture incrementally before deciding whether or not we want to
support it as a public API).

So rather than anything security related, the key reasons I'm
personally interested in moving towards requiring main-relative
imports to be explicit are a matter of making it easier to reason
about a piece of code just by reading it, as well as automatically
avoiding certain classes of beginner bugs (i.e. essentially the same
arguments PEP 328 put forward for the previous switch away from
implicit relative imports in package submodules:
https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports).

Currently, main relative imports look like this:

    import helper

This means that at the point of reading it, you don't know whether
"helper" is independently redistributed, or if it's expected to be
distributed alongside the main script.

By contrast:

    from . import helper

Makes it clear that "helper" isn't a 3rd party thing, it's meant to be
distributed alongside the main script, and if it's missing, you don't
want to pick up any arbitrary top level module that happens to be
called "helper".

Reaching a point where we require main relative imports to be written
as "from . import helper" also means that a script called "socket.py"
could include the statement "import socket" and actually get the
standard library's socket module as it expected - the developer of
such a script would have to write "from . import socket" in order to
reimport the main script as a module.

Cheers,
Nick.

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