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

[Guido van Rossum]

I really don't want people to start using the "from . import foo" idiom for
their first steps into programming. It seems a reasonable "defensive
programming" maneuver  to put in scripts and apps made by professional
Python programmers for surprise-free wide distribution, but (like many of
those) should not be part of the learning experience.

On Sun, Jun 4, 2017 at 12:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170604/81c0a9f0/attachment.html>