[ python-Bugs-947380 ] sys.path is wrong in some cases

SourceForge.net noreply at sourceforge.net
Thu May 20 20:06:42 EDT 2004


Bugs item #947380, was opened at 2004-05-03 17:46
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Ori Berger (orib)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path is wrong in some cases

Initial Comment:
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.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-05-20 17:06

Message:
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

----------------------------------------------------------------------

Comment By: Ori Berger (orib)
Date: 2004-05-03 17:59

Message:
Logged In: YES 
user_id=67862

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470



More information about the Python-bugs-list mailing list