Repository navigation
CLI option for isolated mode #60703
Description
Activity
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.
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.comProfessional 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.
I'm catching up on some old patches. What shall I do about this patch? Does anybody want to review or intervene it?
It applies cleanly, builds without noticeable problems and does what it's advertised to do. In other words, looks great to me!
I say go for it.
"python -I" and "spython" sound like two ways to get the same results. I would prefer to only have one way.
We don't have "spython" yet. Py_IsolatedFlag is also required if we ever going to have "spython", too. We can always remove the command line flag before Python 3.4 hits beta.
On Jun 20, 2013, at 02:26 PM, STINNER Victor wrote:
"python -I" and "spython" sound like two ways to get the same results. I
would prefer to only have one way.Where does spython come from?
Personally, I'd much rather this be an option on the existing python
executable (i.e.python -I) than some other command. That makes it easier
to discover and promote.It comes from Nick and http://www.python.org/dev/peps/pep-0432/ . Once PEP-432 is in place we can easily create variants of Python binaries with special flags.
I'm in favor with python -I, too.
CPython's startup sequence and collection of global flags are organically
evolved madness, so I think adding even more complexity to them is a bad
idea. When you're in a hole, the first thing to do is *stop digging*.I could use help laying the foundations for PEP-432 though - getting the
separate Programs directory split out, breaking up the monstrosity that is
pythonrun.c, etc. Implementing that basic refactoring in default will make
it more feasible to keep the PEP branch up to date without major conflicts.
On 21 Jun 2013 00:40, "Christian Heimes" <report@bugs.python.org> wrote:Christian Heimes added the comment:
It comes from Nick and http://www.python.org/dev/peps/pep-0432/ . Once
PEP-432 is in place we can easily create variants of Python binaries with
special flags.I'm in favor with python -I, too.
----------
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue16499\>
I've come around to the idea of having this available as an option in the default interpreter. A separate binary could then just make it the default behaviour (leaning on PEP-432 to do so), which is more shebang line friendly and allows Linux distros to better distinguish between "default behaviour of Python when running user scripts" and "default behaviour of Python when running system applications" in a way that simple symlinks can't. However, whether or not to provide such a binary (and whether or not to rewrite shebang lines in system packages to use it) would become our problem rather than an upstream problem.
So +1 from me for a -I isolated mode, and I'll adjust PEP-432 as necessary to cope.
python-dev commented
on Aug 10, 2013 python-devmannequinMannequinNew changeset 06c39789061e by Christian Heimes in branch 'default':
typo, changeset dd0d751cc7f1 belongs to issue bpo-16499 not issue bpo-16400
http://hg.python.org/cpython/rev/06c39789061eFor the record (since it took me a while to figure it out), the changeset that this was committed in is dd0d751cc7f1.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: