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

Traceback display code can attempt to open a file named "<stdin>" #43572

Closed
nmm mannequin opened this issue Jun 29, 2006 · 11 comments
Closed

Traceback display code can attempt to open a file named "<stdin>" #43572

nmm mannequin opened this issue Jun 29, 2006 · 11 comments
Labels
3.11 bug and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@nmm
Copy link
Mannequin

nmm mannequin commented Jun 29, 2006

BPO 1514420
Nosy @pitrou, @devdanzin, @ambv, @iritkatriel
PRs
  • bpo-1514420: Do not attempt to open files with names in <>s when form… #28143
  • 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 = None
    closed_at = <Date 2021-09-20.15:11:21.933>
    created_at = <Date 2006-06-29.16:13:21.000>
    labels = ['interpreter-core', 'type-bug', '3.11']
    title = 'Traceback display code can attempt to open a file named "<stdin>"'
    updated_at = <Date 2021-09-20.15:11:21.932>
    user = 'https://bugs.python.org/nmm'

    bugs.python.org fields:

    activity = <Date 2021-09-20.15:11:21.932>
    actor = 'lukasz.langa'
    assignee = 'none'
    closed = True
    closed_date = <Date 2021-09-20.15:11:21.933>
    closer = 'lukasz.langa'
    components = ['Interpreter Core']
    creation = <Date 2006-06-29.16:13:21.000>
    creator = 'nmm'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 1514420
    keywords = ['patch']
    message_count = 11.0
    messages = ['60931', '60932', '84515', '86735', '216697', '216742', '216743', '380347', '383094', '402241', '402242']
    nosy_count = 7.0
    nosy_names = ['ctheune', 'pitrou', 'nmm', 'ajaksu2', 'zbysz', 'lukasz.langa', 'iritkatriel']
    pr_nums = ['28143']
    priority = 'low'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue1514420'
    versions = ['Python 3.11']

    @nmm
    Copy link
    Mannequin Author

    nmm mannequin commented Jun 29, 2006

    Now, exactly WHY is it looking for a file called
    <stdin>? :-)

    This bug has been present since at least 2.3.3 - I
    can't be bothered to
    check back further. Not surprisingly, it causes
    misbehaviour if there
    is a file called <stdin> in any of the places searched,
    but it doesn't
    strike me as the world's most catastrophic bug.

    strace -e open python
    Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
    [GCC 4.1.0 (SUSE Linux)] on linux2
    >>> import dismal
    open("dismal.so", O_RDONLY)             = -1 ENOENT (No
    such file or directory)open("dismalmodule.so",
    O_RDONLY)       = -1 ENOENT (No such file or directory)
    open("dismal.py", O_RDONLY)             = -1 ENOENT (No
    such file or directory)
    open("dismal.pyc", O_RDONLY)            = -1 ENOENT (No
    such file or directory)
    open("/home/nmm/Python_2.5/lib/python2.5/dismal.so",
    O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/home/nmm/Python_2.5/lib/python2.5/<stdin>",
    O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/<stdin>",
    O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/<stdin>",
    O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/<stdin>",
    O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/home/nmm/Python_2.5/lib/python2.5/site-packages/<stdin>",
    O_RDONLY) = -1 ENOENT (No such file or directory)
      File "<stdin>", line 1, in <module>
    ImportError: No module named dismal
    >>>

    @nmm nmm mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Jun 29, 2006
    @ronaldoussoren
    Copy link
    Contributor

    Logged In: YES
    user_id=580910

    It's probably looking for a file named <stdin> because the co_filename
    attribute for code that's executed from the interactive prompt has that value:

    >>> import sys
    >>> f = sys._getframe(0)
    >>> f.f_code.co_filename
    '<stdin>'

    I agree that looking for that file is rather pointless and a bug.

    @devdanzin
    Copy link
    Mannequin

    devdanzin mannequin commented Mar 30, 2009

    Confirmed in py3k and trunk. It's also possible to create a file named
    "<stdin>", I seem to recall discussion on this.

    @devdanzin devdanzin mannequin added type-bug An unexpected behavior, bug, or error labels Mar 30, 2009
    @zbysz
    Copy link
    Mannequin

    zbysz mannequin commented Apr 28, 2009

    The bug is certainly not catastrophic, but creates
    a slight security risk:

    ln -s /etc/shadow '<stdin>'
    some-suid-program -with-error

    or whatever.

    @ctheune
    Copy link
    Mannequin

    ctheune mannequin commented Apr 17, 2014

    I don't think the security risk exists due to this bug. As Python is searching for various places anyway, an attacker could just symlink one of those places anyway instead of '<stdin>'.

    @pitrou
    Copy link
    Member

    pitrou commented Apr 17, 2014

    The problem is not in the import, but when displaying the traceback of the exception. In other words, if you catch the exception, no attempt to open "<stdin>" happens:

    $ strace -e open ./python
    [...]
    Python 3.5.0a0 (default:3417a95df7e2, Apr 16 2014, 17:57:12) 
    [GCC 4.8.1] on linux
    [...]
    >>> 
    >>> try: import dismal
    ... except ImportError: pass
    ... 
    >>>

    @pitrou pitrou changed the title Missing module code does spurious file search Traceback display code can attempt to open a file named "<stdin>" Apr 17, 2014
    @pitrou pitrou changed the title Missing module code does spurious file search Traceback display code can attempt to open a file named "<stdin>" Apr 17, 2014
    @pitrou
    Copy link
    Member

    pitrou commented Apr 17, 2014

    Also, by construction it will only happen if the import happens under the interpreter prompt (hence the "<stdin>" filename).

    I honestly don't think this deserves introducing some complication, only to avoid a couple filesystem accesses.

    @iritkatriel
    Copy link
    Member

    I was able to reproduce it on 3.8, but I'm confused about where the open is happening because linecache.updatecache tries to avoid this:

    if not filename or (filename.startswith('<') and filename.endswith('>')):
            return []

    @iritkatriel iritkatriel added 3.8 only security fixes 3.9 only security fixes 3.10 only security fixes labels Nov 4, 2020
    @iritkatriel
    Copy link
    Member

    Ok, I'm unconfused now - this is the C version of the traceback, in _Py_DisplaySourceLine, not the traceback.py one that uses linecache.

    It wouldn't be hard to add the check for "<>" in the filename there. Is there a reason not to do it?

    @iritkatriel iritkatriel added 3.11 bug and security fixes and removed 3.8 only security fixes 3.9 only security fixes 3.10 only security fixes labels Sep 3, 2021
    @ambv
    Copy link
    Contributor

    ambv commented Sep 20, 2021

    New changeset f71300c by Irit Katriel in branch 'main':
    bpo-1514420: Do not attempt to open files with names in <>s when formatting an exception (GH-28143)
    f71300c

    @ambv
    Copy link
    Contributor

    ambv commented Sep 20, 2021

    Fixed for Python 3.11. Thanks! ✨ 🍰 ✨

    @ambv ambv closed this as completed Sep 20, 2021
    @ambv ambv closed this as completed Sep 20, 2021
    @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
    3.11 bug and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants