Christian Heimes, author of the -I option (isolated mode), asked me to open an issue to check if the following behaviour is correct (safe in term of security).

"python3 directory" inserts "directory" at sys.path[0], even in isolated mode. Example:
---
vstinner@apu$ mkdir directory
vstinner@apu$ echo "import pprint, sys; pprint.pprint(sys.path)" > directory/__main__.py

vstinner@apu$ python3 directory
['directory',
 '/usr/lib64/python3.6',
 ...]

# Same behaviour with -I
vstinner@apu$ python3 -I directory
['directory',
 '/usr/lib64/python3.6',
 ...]
---


Same behaviour for a ZIP file:
---
vstinner@apu$ cd directory/
vstinner@apu$ zip ../testzip.zp __main__.py 
  adding: __main__.py (deflated 20%)
vstinner@apu$ cd ..
vstinner@apu$ python3 testzip.zip
python3: can't open file 'testzip.zip': [Errno 2] No such file or directory
vstinner@apu$ mv testzip.zp testzip.zip 
'testzip.zp' -> 'testzip.zip'

vstinner@apu$ python3 testzip.zip
['testzip.zip',
 '/usr/lib64/python3.6',
 ...]

# Same behaviour with -I
vstinner@apu$ python3 -I testzip.zip
['testzip.zip',
 '/usr/lib64/python3.6',
 ...]
---

The -I option:
https://docs.python.org/dev/using/cmdline.html#id2

"python3 directory" and "python3 testzip.zip" are implemented by calling runpy._run_module_as_main("__main__", set_argv0). Currently, sys.path is modified before calling _run_module_as_main().

Would it be possible to pass an additional path to importlib to import __main__, without modifying sys.path?

See also https://github.com/python/cpython/pull/4868 : I propose a change to factorize the code, but the side effect is that sys.path is now modified before "import readline" (when using the -i option, like "python3 -i directory").

Since the directory is where the code that is being executed exists don't you have to implicitly trust that directory is secure? Otherwise how can you even trust the code you're choosing to execute?

> Since the directory is where the code that is being executed exists don't you have to implicitly trust that directory is secure? Otherwise how can you even trust the code you're choosing to execute?

The question is if the following example must work with -I:

---
vstinner@apu$ mkdir directory
vstinner@apu$ echo "import submodule" > directory/__main__.py
vstinner@apu$ echo 'print("submodule", __file__)' > directory/submodule.py

vstinner@apu$ python3 directory
submodule directory/submodule.py

vstinner@apu$ python3 -I directory
submodule directory/submodule.py
---

Do you expect that "python3 directory" allows imports from directory/?

The second question is if directory must be prepended to sys.path (start), or if it must be appended to sys.path (end)?

Prepend allows to override stdlib imports, whereas append risks of conflicts with others paths in sys.path and so loading the "wrong" submodule.

For example, I still expect to run __main__ from directory in the following example:

---
vstinner@apu$ mkdir other
vstinner@apu$ echo "print('other main')" > other/__main__.py
vstinner@apu$ PYTHONPATH=other python3 directory
submodule directory/submodule.py
---

I vote that it has to work and it should be prepended.

The more interesting part is the relative directory and how often is it resolved? Can you change a program's imports by inducing it to change its working directory immediately after startup (or before any lazy imports)? If so, we should resolve it to a full path when adding it, regardless of -I.

Having the first entry there is required for local imports to work from the startup script, so I don't see it going anywhere. There have been many discussions about how to deal with the shadowing "problem", but the eventual answer was consenting adults.

A compromise would be to refuse to start on "python3 -I directory" to remain secure and respect -I documentation:

https://docs.python.org/dev/using/cmdline.html#id2

"In isolated mode sys.path contains neither the script’s directory nor the user’s site-packages directory."

Example of error message:

"Running a Python package is incompatible with the isolated mode (-I option)"

> A compromise would be to refuse to start on "python3 -I directory" to remain secure

What would that achieve, considering that "python3 -I directory/__main__.py" would let you start with exactly the same sys.path?[*]

The only change that might be of any value would be to resolve the path as early as possible so that an absolute path is added to sys.path[0]. 

Not adding the directory of the startup script is a breaking change with no security benefits -- it has to stay there. -I is not a protection against command-line arguments.

[*] On Windows, using the filename seems to resolve the directory while using just the directory name does not. I'm not sure why they aren't identical, and obviously I think they should be, but I'd expect the initialization work to streamline it (when getpath.c becomes sensible).

When executing a sys.path entry, you're executing that *entire* entry (whether it's a directory or zipfile). This isn't a bug, and it isn't in conflict with the assurances offered by isolated mode (it would only be a problem if running "~/code/mydirectory" added "~/code" to sys.path).

(However, the behaviour Steve is describing suggests that sys.path[0] initialisation may have problems on Windows that the test suite isn't picking up - "-I" should *not* add the script directory to the path, and directory execution should always add an absolute path, not a relative one)