I like to propose a new option for the Python interpreter:

  python -I

It shall start the interpreter in isolated mode which ignores any
environment variables set by the user and any files installed by the
user. The mode segregate a Python program from anything an unpriviliged
user is able to modify and uses only files that are installed by a
system adminstrator.

The isolated mode implies -E (ignore all PYTHON* environment vars) and
-s (don't add user site directory). It also refrains from the inclusion
of '' or getcwd() to sys.path. TKinter doesn't load and execute Python
scripts from the user's home directory. Other parts of the stdlib should
be checked, too.

The option is intended for OS and application scripts that doesn't want
to become affected by user installed files or files in the current
working path of a user.

The idea is motivated by a couple of bug reports, for example:

https://bugs.launchpad.net/bugs/938869  lsb_release crashed with SIGABRT
in Py_FatalError()

http://bugs.python.org/issue16202  sys.path[0] security issues

http://bugs.python.org/issue16248  Security bug in tkinter allows for
untrusted, arbitrary code execution.

---

The idea has been discussed at http://mail.python.org/pipermail/python-ideas/2012-November/017766.html.

The first patch implements the arg parsing, sys.flags, PySys_SetArgv() modification that doesn't include the current directory as sys.path[0] and some doc updates.

Open issue:

 - MAL has addressed concerns that '-I' is too similar to GCC's -I (include path) option
 - Is 'isolated mode' a good term to describe the feature? IMO 'restricted mode' is also a good name but it sounds too similar to PyPy's restricted python.

I don't think we need to worry about overlapping with gcc; -B, -b, -c, -d, etc. are all used by gcc for some reason or another.

+1 from me. "-I" and "isolated" sound fine to me.

The patch needs to add some tests. Also the docs need some "versionadded" / "versionchanged" markers.

On Nov 18, 2012, at 05:16 PM, Antoine Pitrou wrote:

>Antoine Pitrou added the comment:
>
>+1 from me. "-I" and "isolated" sound fine to me.

I haven't reviewed the patch yet, but based on the email discussions, I'm also
+1 for the concept, option name, and terminology.

Here is a new patch with some tests.

-I looks as antonym to -i.  This is good.

See also related issue12238 and issue10496.

Hint: if you refers to issue as issueXXX, you can see an issue title when hover mouse over link.

On 18.11.2012 15:30, Christian Heimes wrote:
> 
> Christian Heimes added the comment:
> 
> The first patch implements the arg parsing, sys.flags, PySys_SetArgv() modification that doesn't include the current directory as sys.path[0] and some doc updates.
> 
> Open issue:
> 
>  - MAL has addressed concerns that '-I' is too similar to GCC's -I (include path) option
>  - Is 'isolated mode' a good term to describe the feature? IMO 'restricted mode' is also a good name but it sounds too similar to PyPy's restricted python.

Some other possible names:

 - unmodified mode (-U)
 - encapsulated mode (-e)
 - installation only mode (-I)
 - non-local mode (-l)

Since this mode will often be used for testing Python installation
and setup issues, perhaps emphasizing on the testing nature would
be good...

 - test installation mode (-T)

FWIW: Isolated and -I works for me as well.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 19 2012)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

New patch with typo fixes and update for recent modification in the make_flags() function.

Marc:
The patch was motivated by use cases like Barry's issue with 3rd party software that accidentally messes with Python scripts like lsb_release. Your use case (testing) is valid but not the main focus here. Unmodified mode doesn't fit the bill either, Python can still import system wide packages or modifications from a venv.

Apropos venv, I need to check how the option is affected by venv.

How shall I handle venv? I'm reluctant to disable venv in site.py although it allows a user to modify sys.path. However it's only an issue under two circumstances:

(1) The user either needs write permissions to the parent directory of the python executable. 
(2) The script doesn't hard code the path to the interpreter in its shebang.

Point 1 allows the user to mess with the system in more serious ways. The second point can be avoided with a correctly written shebang line.

> How shall I handle venv? I'm reluctant to disable venv in site.py
> although it allows a user to modify sys.path. However it's only an
> issue under two circumstances:
> 
> (1) The user either needs write permissions to the parent directory of
> the python executable. 
> (2) The script doesn't hard code the path to the interpreter in its
> shebang.
> 
> Point 1 allows the user to mess with the system in more serious ways.
> The second point can be avoided with a correctly written shebang line.

I agree that venv shouldn't be a problem.

The "system Python" idea in PEP 432 is aimed at providing an alternate interpreter binary which changes the default behaviour to be appropriate for system utilities, while allowing such features to be enabled selectively.