classification
Title: CLI option for isolated mode
Type: security Stage: committed/rejected
Components: Interpreter Core Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: asvetlov, barry, brett.cannon, christian.heimes, eric.araujo, haypo, lemburg, mdengler, ncoghlan, pitrou, python-dev, r.david.murray, yaccz
Priority: normal Keywords: needs review, patch

Created on 2012-11-18 14:26 by christian.heimes, last changed 2014-02-24 14:58 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
isolatemode3.patch christian.heimes, 2012-11-19 19:55 review
Messages (25)
msg175874 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-18 14:26
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.
msg175875 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-18 14:29
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.
msg175882 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-11-18 15:38
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.
msg175890 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-11-18 17:16
+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.
msg175902 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-11-18 18:54
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.
msg175918 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-18 20:19
Here is a new patch with some tests.
msg175921 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-11-18 21:04
-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.
msg175949 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2012-11-19 08:20
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/
msg175965 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-19 19:55
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.
msg176121 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-11-22 19:08
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.
msg176122 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-11-22 19:29
> 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.
msg179169 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2013-01-06 04:09
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.
msg191493 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-06-19 20:45
I'm catching up on some old patches. What shall I do about this patch? Does anybody want to review or intervene it?
msg191512 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-06-20 14:05
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.
msg191515 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2013-06-20 14:26
"python -I" and "spython" sound like two ways to get the same results. I would prefer to only have one way.
msg191516 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-06-20 14:35
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.
msg191517 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-06-20 14:38
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.
msg191519 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-06-20 14:40
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.
msg191525 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2013-06-20 15:15
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>
> _______________________________________
>
msg192170 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2013-07-02 02:12
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.
msg192171 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-07-02 02:19
On Jul 02, 2013, at 02:12 AM, Nick Coghlan wrote:

>So +1 from me for a -I isolated mode, and I'll adjust PEP 432 as necessary to
>cope.

PEP 394 is probably related to any such additional binary.
msg194175 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-08-02 13:33
Nick,

you have deferred PEP 432 [1]. Do you mind if I check in the isolate mode for 3.4 and help you with PEP 432 for 3.5?


[1] http://www.python.org/dev/peps/pep-0432/#pep-deferral
msg194180 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2013-08-02 15:16
Yep, sounds good to me ("don't wait for PEP 432" is what I meant to imply above, but I wasn't very clear about it)
msg194794 - (view) Author: Roundup Robot (python-dev) Date: 2013-08-10 14:38
New changeset 06c39789061e by Christian Heimes in branch 'default':
typo, changeset dd0d751cc7f1 belongs to issue #16499 not issue #16400
http://hg.python.org/cpython/rev/06c39789061e
msg212105 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-02-24 14:58
For the record (since it took me a while to figure it out), the changeset that this was committed in is dd0d751cc7f1.
History
Date User Action Args
2014-02-24 14:58:34r.david.murraysetnosy: + r.david.murray
messages: + msg212105
2013-08-10 14:41:44christian.heimessetstatus: open -> closed
resolution: fixed
stage: patch review -> committed/rejected
2013-08-10 14:38:31python-devsetnosy: + python-dev
messages: + msg194794
2013-08-02 15:16:54ncoghlansetmessages: + msg194180
2013-08-02 13:33:34christian.heimessetmessages: + msg194175
2013-07-02 02:19:49barrysetmessages: + msg192171
2013-07-02 02:12:44ncoghlansetmessages: + msg192170
2013-06-20 15:15:41ncoghlansetmessages: + msg191525
2013-06-20 14:40:11christian.heimessetmessages: + msg191519
2013-06-20 14:38:07barrysetmessages: + msg191517
2013-06-20 14:35:53christian.heimessetmessages: + msg191516
2013-06-20 14:26:44hayposetmessages: + msg191515
2013-06-20 14:05:48barrysetmessages: + msg191512
2013-06-19 20:45:38christian.heimessetmessages: + msg191493
2013-04-24 11:43:01yacczsetnosy: + yaccz
2013-04-22 22:45:37hayposetnosy: + haypo
2013-01-06 19:46:47serhiy.storchakasetnosy: - serhiy.storchaka
2013-01-06 04:09:20ncoghlansetmessages: + msg179169
2012-12-03 15:39:21asvetlovsetnosy: + asvetlov
2012-11-28 13:46:25mdenglersetnosy: + mdengler
2012-11-28 07:02:22ncoghlansetnosy: + ncoghlan
2012-11-22 19:29:43pitrousetmessages: + msg176122
2012-11-22 19:08:10christian.heimessetmessages: + msg176121
2012-11-19 19:55:58christian.heimessetfiles: + isolatemode3.patch

messages: + msg175965
2012-11-19 19:36:18christian.heimessetfiles: - isolatemode2.patch
2012-11-19 19:36:10christian.heimessetfiles: - isolatemode.patch
2012-11-19 08:20:30lemburgsetmessages: + msg175949
2012-11-18 21:04:03serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg175921
2012-11-18 20:19:20christian.heimessetfiles: + isolatemode2.patch

messages: + msg175918
2012-11-18 18:54:30barrysetmessages: + msg175902
2012-11-18 17:16:40pitrousetnosy: + pitrou
messages: + msg175890
2012-11-18 15:38:30brett.cannonsetnosy: + brett.cannon
messages: + msg175882
2012-11-18 15:24:09eric.araujosetnosy: + eric.araujo
2012-11-18 14:45:12christian.heimessetkeywords: + needs review
components: + Interpreter Core
2012-11-18 14:30:00christian.heimessetfiles: + isolatemode.patch
keywords: + patch
messages: + msg175875
2012-11-18 14:26:11christian.heimescreate