Hi everybody, 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. Regards, Christian
On Thu, Nov 8, 2012 at 10:13 PM, Christian Heimes
Hi everybody,
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.
R allows something quite similar with the "--vanilla" option. I can attest that it's also quite helpful for debugging, particularly for working around corrupted startup settings. I do think I slightly prefer "vanilla" to possible I/l ["i" or "L"] confusion, but I do appreciate that long flags are not the norm for Python. Michael
On Nov 08, 2012, at 11:13 PM, Christian Heimes wrote:
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.
As someone who worked on the lsb_release problem, I'm generally supportive of this proposal. Here's a link to the thread on the debian-python mailing list where I suggested "system" scripts always use -Es in the shebang line: http://thread.gmane.org/gmane.linux.debian.devel.python/8188 The responses were cautious but mostly supportive. One poster said: "If I set PYTHONWARNINGS, I want it to affect all Python scripts." I wonder also if we might want some other set of defaults, like -B enabled. Cheers, -Barry
On 08.11.2012 23:13, Christian Heimes wrote:
Hi everybody,
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.
Sounds like a good idea. I'd be interested in this, because it would make debugging user installation problems easier. The only thing I'm not sure about is the option character "-I". It reminds me too much of the -I typically used for include paths in C compilers :-) BTW: In order to have Python applications respect this flag, there should be an easy way to access this flag in Python programs, e.g. sys.ignore_user_env. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 09 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/
Am 09.11.2012 09:19, schrieb M.-A. Lemburg:
Sounds like a good idea. I'd be interested in this, because it would make debugging user installation problems easier.
The only thing I'm not sure about is the option character "-I". It reminds me too much of the -I typically used for include paths in C compilers :-)
I'm open to suggestions for a better name and character. Michael also pointed out that capital i (india) can look like a lower case l (lima). -R is still unused. I hesitate to call it restricted mode because it can be confused with PyPy's restricted Python.
BTW: In order to have Python applications respect this flag, there should be an easy way to access this flag in Python programs, e.g. sys.ignore_user_env.
Of course! I assumed that I don't have to spell it out explicitly. A new CLI option will be accompanied with a new sys.flags attribute like sys.flags.isolated_mode. Christian
On Friday 09 Nov 2012, Christian Heimes wrote:
Am 09.11.2012 09:19, schrieb M.-A. Lemburg:
Sounds like a good idea. I'd be interested in this, because it would make debugging user installation problems easier.
The only thing I'm not sure about is the option character "-I". It reminds me too much of the -I typically used for include paths in C compilers :-)
I'm open to suggestions for a better name and character. Michael also pointed out that capital i (india) can look like a lower case l (lima). -R is still unused. I hesitate to call it restricted mode because it can be confused with PyPy's restricted Python.
Are you restricted to the restricted ASCII set? -^ as an option? The caret isn't already taken on the command line like & or ;. Mind you, it may be best to bite the bullet and go "No one character option". You only get 52 options there and every option wants to be "e" because e's are good (sorry, UK pop quiz pun there). You see it often enough. Since -h is taken for help, you need -x for hex. Picking a character from the long word only gets you so far. Very few z's. So why not just call it a day and use long case rather than contort the language like acronym writers.
On Fri, Nov 9, 2012 at 8:27 AM, Christian Heimes
Am 09.11.2012 09:19, schrieb M.-A. Lemburg:
Sounds like a good idea. I'd be interested in this, because it would make debugging user installation problems easier.
The only thing I'm not sure about is the option character "-I". It reminds me too much of the -I typically used for include paths in C compilers :-)
I'm open to suggestions for a better name and character. Michael also pointed out that capital i (india) can look like a lower case l (lima). -R is still unused. I hesitate to call it restricted mode because it can be confused with PyPy's restricted Python.
Why does it have to be a single letter? Many tools today demand fully spelled out command-line flags for readability, and this also helps avoid clashes and cryptic flags no one remembers anyway. So if you want isolate mode, what's wrong with "--isolated" ? Eli
On Nov 14, 2012, at 05:57 AM, Eli Bendersky wrote:
Why does it have to be a single letter? Many tools today demand fully spelled out command-line flags for readability, and this also helps avoid clashes and cryptic flags no one remembers anyway. So if you want isolate mode, what's wrong with "--isolated" ?
% head -1 foo.py #!/usr/bin/python3 -Es % ./foo.py hello world % head -1 bar.py #!/usr/bin/python3 -E -s % ./bar.py Unknown option: - usage: /usr/bin/python3 [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. So if you need to put multiple options on your shebang line, long options won't work. Cheers, -Barry
On 15/11/12 10:57, Random832 wrote:
On 11/14/2012 4:57 PM, Barry Warsaw wrote:
So if you need to put multiple options on your shebang line, long options won't work. This seems like something that could be worked around in the interpreter.
Shebang lines aren't interpreted by Python, but by the shell. To be precise, it isn't the shell either, but the program loader, I think. But whatever it is, it isn't Python. -- Steven
On Thu, Nov 15, 2012 at 11:25:09AM +1100, Steven D'Aprano
Shebang lines aren't interpreted by Python, but by the shell.
To be precise, it isn't the shell either, but the program loader, I think. But whatever it is, it isn't Python.
By the OS kernel -- it looks into the header to find out if the file to be exec'd is ELF or DWARF or a script -- and then it invokes an appropriate loader. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Wed, Nov 14, 2012, at 19:25, Steven D'Aprano wrote:
Shebang lines aren't interpreted by Python, but by the shell.
To be precise, it isn't the shell either, but the program loader, I think. But whatever it is, it isn't Python.
That's obviously untrue - the shell or the kernel or whatever piece it is doesn't know what an -E or a -s does, it simply passes them to python. Now, as the error messages show, it passes them as a single string rather than (as you would ordinarily expect) as two strings, but it's all _there_ for python to see, even without trying to read it from the file (which it also could do).
On Nov 15, 2012 3:43 PM,
On Wed, Nov 14, 2012, at 19:25, Steven D'Aprano wrote:
Shebang lines aren't interpreted by Python, but by the shell.
To be precise, it isn't the shell either, but the program loader, I think. But whatever it is, it isn't Python.
That's obviously untrue - the shell or the kernel or whatever piece it is doesn't know what an -E or a -s does, it simply passes them to python. Now, as the error messages show, it passes them as a single string rather than (as you would ordinarily expect) as two strings, but it's all _there_ for python to see, even without trying to read it from the file (which it also could do).
It's obviously true. The kernel (or shell, as the case may be) interprets
the shebang line to find the executable an pick out the arguments to pass
to the executable. The executable (Python) then interprets the arguments,
without ever having seen the shebang line.
While python could in theory start reading and interpreting the shebang
line, I don't think there's a sane way to decide when to do so since you
can set the arguments on the command line by invoking scripts explicitly.
participants (11)
-
Barry Warsaw -
Christian Heimes -
Eli Bendersky -
M.-A. Lemburg -
Mark Hackett -
Mike Meyer -
Oleg Broytman -
R. Michael Weylandt -
Random832 -
random832＠fastmail.us
-
Steven D'Aprano