| msg60931 - (view) |
Author: Nick Maclaren (nmm) |
Date: 2006-06-29 16:13 |
| Now, exactly WHY is it looking for a file called ? :-) 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 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/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/nmm/Python_2.5/lib/python2.5/site-packages/", O_RDONLY) = -1 ENOENT (No such file or directory) File "", line 1, in ImportError: No module named dismal >>> |
|
|
| msg60932 - (view) |
Author: Ronald Oussoren (ronaldoussoren) *  |
Date: 2006-07-13 12:04 |
| Logged In: YES user_id=580910 It's probably looking for a file named 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 '' I agree that looking for that file is rather pointless and a bug. |
|
|
| msg84515 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-03-30 05:56 |
| Confirmed in py3k and trunk. It's also possible to create a file named "", I seem to recall discussion on this. |
|
|
| msg86735 - (view) |
Author: Zbyszek Jędrzejewski-Szmek (zbysz) * |
Date: 2009-04-28 13:10 |
| The bug is certainly not catastrophic, but creates a slight security risk: ln -s /etc/shadow '' some-suid-program -with-error or whatever. |
|
|
| msg216697 - (view) |
Author: Christian Theune (ctheune) * |
Date: 2014-04-17 15:29 |
| 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 ''. |
|
|
| msg216742 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-04-17 21:05 |
| 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 "" 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 ... >>> |
|
|
| msg216743 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-04-17 21:06 |
| Also, by construction it will only happen if the import happens under the interpreter prompt (hence the "" filename). I honestly don't think this deserves introducing some complication, only to avoid a couple filesystem accesses. |
|
|
| msg380347 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2020-11-04 17:55 |
| 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 [] |
|
|
| msg383094 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2020-12-15 20:03 |
| 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? |
|
|
| msg402241 - (view) |
Author: Łukasz Langa (lukasz.langa) * |
Date: 2021-09-20 15:10 |
| New changeset f71300cb0442f16ee9abc938e12537aec1eb5979 by Irit Katriel in branch 'main': bpo-1514420: Do not attempt to open files with names in <>s when formatting an exception (GH-28143) https://github.com/python/cpython/commit/f71300cb0442f16ee9abc938e12537aec1eb5979 |
|
|
| msg402242 - (view) |
Author: Łukasz Langa (lukasz.langa) * |
Date: 2021-09-20 15:11 |
| Fixed for Python 3.11. Thanks! ✨ 🍰 ✨ |
|
|