sys.path is wrong in some cases

[orib]

BPO	947380
Nosy	@birkenfeld, @josiahcarlson

^{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 2007-03-06.18:06:53.000>
created_at = <Date 2004-05-04.00:46:44.000>
labels = ['interpreter-core']
title = 'sys.path is wrong in some cases'
updated_at = <Date 2007-03-06.18:06:53.000>
user = 'https://bugs.python.org/orib'

bugs.python.org fields:

activity = <Date 2007-03-06.18:06:53.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-05-04.00:46:44.000>
creator = 'orib'
dependencies = []
files = []
hgrepos = []
issue_num = 947380
keywords = []
message_count = 5.0
messages = ['20673', '20674', '20675', '20676', '20677']
nosy_count = 4.0
nosy_names = ['georg.brandl', 'josiahcarlson', 'zseil', 'orib']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue947380'
versions = []

[orib]

Python version tested: 2.3.3 (But if I read the cvs
annotate correctly, this goes all the way back to 2.0)
OS Version tested: Win2K (but any win32 version should
behave the same).

On Windows, sys,path sometimes contains the 'current
working directory', in which the Python process was
started, while the interpreter is still initializing;
it shouldn't be there until after the interpreter had
completed initializing and is ready for batch or
interactive execution.

How to reproduce:

Use plain-vanilla 2.3.3 Python, without _any_
additional module installed. The
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath
registry key must NOT have any subkey (this is true for
a fresh install, but might not be true if packages were
installed earlier).

Go to a subdirectory of your choice, e.g.,
C:\HoverCraft\Eels, and run (assuming Python is in
c:\python23)

c:\python23\python -c "import sys; print sys.path"

The first entry should be the current directory or ''.
That's ok - it was added at the end of initialization.
The second entry will be a .zip file where the .dll is;
That's also ok. The third entry should be the current
directory (or '') again. THIS IS NOT OK.

How this was discovered:

To give credit where credit is due, my friend Oren
Gampel created a file called 'stat.py' in a directory,
and from that moment on, Python started complaining
about failing to import site. The reason is that 'site'
imports 'ntpath', which imports 'stat', which
unfortunately imported the new 'stat' rather than the
library 'stat'.

In some convoluted settings, this might have security
implications - e.g., if an administrator starts a
Python script in a directory to which a user has write
permissions, this could result in a privelege
escalation (even if the script has no import statements
at all - the implicit "import site" is sufficient).

I'm submitting a 2-line patch to the patch tracker (and
one of them is a comment!) that seems to solve this
problem.

[orib]

Logged In: YES
user_id=67862

Patch uploaded to http://python.org/sf/947386

[josiahcarlson]

Logged In: YES
user_id=341410

This is the old "module in current path shadows standard
library module" issue which will be fixed in Python 2.4 via
absolute and relative imports as stated in PEP-328:

http://python.org/peps/pep-0328.html

[zseil]

This was fixed in Python 2.5 with patch bpo-1232023:
http://www.python.org/sf/1232023

[birkenfeld]

Closing accordingly.