Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLI option for isolated mode #60703

Closed
tiran opened this issue Nov 18, 2012 · 25 comments
Closed

CLI option for isolated mode #60703

tiran opened this issue Nov 18, 2012 · 25 comments
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-security A security issue

Comments

@tiran
Copy link
Member

tiran commented Nov 18, 2012

BPO 16499
Nosy @malemburg, @warsaw, @brettcannon, @ncoghlan, @pitrou, @vstinner, @tiran, @merwok, @bitdancer, @asvetlov
Files
  • isolatemode3.patch
  • 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:

    assignee = 'https://github.com/tiran'
    closed_at = <Date 2013-08-10.14:41:44.541>
    created_at = <Date 2012-11-18.14:26:11.590>
    labels = ['type-security', 'interpreter-core']
    title = 'CLI option for isolated mode'
    updated_at = <Date 2014-02-24.14:58:34.198>
    user = 'https://github.com/tiran'

    bugs.python.org fields:

    activity = <Date 2014-02-24.14:58:34.198>
    actor = 'r.david.murray'
    assignee = 'christian.heimes'
    closed = True
    closed_date = <Date 2013-08-10.14:41:44.541>
    closer = 'christian.heimes'
    components = ['Interpreter Core']
    creation = <Date 2012-11-18.14:26:11.590>
    creator = 'christian.heimes'
    dependencies = []
    files = ['28043']
    hgrepos = []
    issue_num = 16499
    keywords = ['patch', 'needs review']
    message_count = 25.0
    messages = ['175874', '175875', '175882', '175890', '175902', '175918', '175921', '175949', '175965', '176121', '176122', '179169', '191493', '191512', '191515', '191516', '191517', '191519', '191525', '192170', '192171', '194175', '194180', '194794', '212105']
    nosy_count = 13.0
    nosy_names = ['lemburg', 'barry', 'brett.cannon', 'ncoghlan', 'pitrou', 'vstinner', 'christian.heimes', 'eric.araujo', 'r.david.murray', 'asvetlov', 'python-dev', 'mdengler', 'yaccz']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'security'
    url = 'https://bugs.python.org/issue16499'
    versions = ['Python 3.4']

    @tiran
    Copy link
    Member Author

    tiran commented Nov 18, 2012

    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.

    @tiran tiran self-assigned this Nov 18, 2012
    @tiran tiran added the type-security A security issue label Nov 18, 2012
    @tiran
    Copy link
    Member Author

    tiran commented Nov 18, 2012

    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.

    @tiran tiran added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Nov 18, 2012
    @brettcannon
    Copy link
    Member

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Nov 18, 2012

    +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.

    @warsaw
    Copy link
    Member

    warsaw commented Nov 18, 2012

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Nov 18, 2012

    Here is a new patch with some tests.

    @serhiy-storchaka
    Copy link
    Member

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

    See also related bpo-12238 and bpo-10496.

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

    @malemburg
    Copy link
    Member

    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/

    @tiran
    Copy link
    Member Author

    tiran commented Nov 19, 2012

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Nov 22, 2012

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Nov 22, 2012

    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.

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Jan 6, 2013

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Jun 19, 2013

    I'm catching up on some old patches. What shall I do about this patch? Does anybody want to review or intervene it?

    @warsaw
    Copy link
    Member

    warsaw commented Jun 20, 2013

    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.

    @vstinner
    Copy link
    Member

    "python -I" and "spython" sound like two ways to get the same results. I would prefer to only have one way.

    @tiran
    Copy link
    Member Author

    tiran commented Jun 20, 2013

    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.

    @warsaw
    Copy link
    Member

    warsaw commented Jun 20, 2013

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Jun 20, 2013

    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.

    @ncoghlan
    Copy link
    Contributor

    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\>


    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Jul 2, 2013

    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.

    @warsaw
    Copy link
    Member

    warsaw commented Jul 2, 2013

    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.

    @tiran
    Copy link
    Member Author

    tiran commented Aug 2, 2013

    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

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Aug 2, 2013

    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)

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Aug 10, 2013

    New 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/06c39789061e

    @tiran tiran closed this as completed Aug 10, 2013
    @bitdancer
    Copy link
    Member

    For the record (since it took me a while to figure it out), the changeset that this was committed in is dd0d751cc7f1.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) type-security A security issue
    Projects
    None yet
    Development

    No branches or pull requests

    9 participants