You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Local files shadow system modules, even from system modules #66368
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=Noneclosed_at=<Date2014-08-08.11:48:58.187>created_at=<Date2014-08-08.09:32:09.977>labels= ['type-security', 'interpreter-core', 'invalid']
title='Local files shadow system modules, even from system modules'updated_at=<Date2014-08-08.11:48:58.181>user='https://bugs.python.org/drt24'
In Python 3.4 (but not 3.2 or 2.7) when a system module does an import then files with the same name in the directory of the original python script which match that name are used.
E.g.
With a directory containing:
test.py:
#!/usr/bin/env python3
from collections import OrderedDict
print('do stuff')
Running test.py will cause:
EXPLOIT!
Traceback (most recent call last):
File "./test.py", line 4, in <module>from collections import OrderedDict
File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>from operator import itemgetter as _itemgetter, eq as _eq
ImportError: cannot import name 'itemgetter'
While test.py is perfectly innocent it is in the same directory as the nasty operator.py and test.py makes no reference at all to operator.py but when 'collections' is imported it imports from operator which is resolved to operator.py in the local directory
This is a security vulnerability because it is possible to verify that a python script is safe to run by reading its code and then on running it find that other code is implicitly loaded by the system libraries which is never referenced in the original file or part of any of the standard libraries.
It is also rather confusing but a related issue is already filed for that in bpo-21202.
This is similar to the standard name shadowing trap http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap but now applies to other files in the source directory in a way which it didn't in previous versions of python. I suspect this was introduced in python 3.3 through changes to the import system and __init__.py becoming optional but I don't have a 3.3 install to check that with.
sys.path here is: ['/auto/homes/drt24/pythontest', '/usr/lib/python3.4', '/usr/lib/python3.4/plat-x86_64-linux-gnu', '/usr/lib/python3.4/lib-dynload', '/usr/local/lib/python3.4/dist-packages', '/usr/lib/python3/dist-packages']
Running Python 3.4.0-0ubuntu2 on Ubuntu 14.04.1 LTS with Linux 3.13.0-32-generic
This is not new behaviour. It's just normal system shadowing:
$ python test.py
Traceback (most recent call last):
File "test.py", line 1, in <module>import collections
File "/usr/lib64/python2.7/collections.py", line 9, in <module>from operator import itemgetter as _itemgetter, eq as _eq
ImportError: cannot import name itemgetter
Avoiding that behaviour is what the new isolated mode is for:
Activity
drt24 commentedon Aug 8, 2014
In Python 3.4 (but not 3.2 or 2.7) when a system module does an import then files with the same name in the directory of the original python script which match that name are used.
E.g.
With a directory containing:
test.py:
#!/usr/bin/env python3
from collections import OrderedDict
print('do stuff')
operator.py:
#!/usr/bin/env python3
print('EXPLOIT!')
While test.py is perfectly innocent it is in the same directory as the nasty operator.py and test.py makes no reference at all to operator.py but when 'collections' is imported it imports from operator which is resolved to operator.py in the local directory
This is a security vulnerability because it is possible to verify that a python script is safe to run by reading its code and then on running it find that other code is implicitly loaded by the system libraries which is never referenced in the original file or part of any of the standard libraries.
It is also rather confusing but a related issue is already filed for that in bpo-21202.
This is similar to the standard name shadowing trap http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-name-shadowing-trap but now applies to other files in the source directory in a way which it didn't in previous versions of python. I suspect this was introduced in python 3.3 through changes to the import system and __init__.py becoming optional but I don't have a 3.3 install to check that with.
sys.path here is: ['/auto/homes/drt24/pythontest', '/usr/lib/python3.4', '/usr/lib/python3.4/plat-x86_64-linux-gnu', '/usr/lib/python3.4/lib-dynload', '/usr/local/lib/python3.4/dist-packages', '/usr/lib/python3/dist-packages']
Running Python 3.4.0-0ubuntu2 on Ubuntu 14.04.1 LTS with Linux 3.13.0-32-generic
ncoghlan commentedon Aug 8, 2014
This is not new behaviour. It's just normal system shadowing:
Avoiding that behaviour is what the new isolated mode is for:
$ ~/devel/py34/python -I test.py $