classification
Title: os.path.realpath gets confused when symlinks include '..'
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: duplicate
Dependencies: Superseder: symlinks incorrectly resolved on POSIX platforms
View: 6975
Assigned To: Nosy List: hynek, o11c, pitrou, r.david.murray
Priority: high Keywords:

Created on 2012-06-26 19:04 by o11c, last changed 2012-06-26 21:36 by r.david.murray. This issue is now closed.

Messages (4)
msg164090 - (view) Author: Ben Longbons (o11c) * Date: 2012-06-26 19:03
I encountered this bug with the following filesystem layout

project/build/bin/main-gdb.py -> ../src/main-gdb.py
project/build/src -> ../src/
project/src/main-gdb.py -> ../py/main-gdb.py
project/py/main-gdb.py

where root/py/main-gdb.py contains
import os
print(os.path.realpath(__file__))

Actual Result:
project/build/py/main-gdb.py
instead of 
project/py/main-gdb.py

The cause of this bug is the fact that os.path._resolve_link calls os.path.normpath, which is not symlink-safe.
Specically, this is bad:
os.path.normpath('project/build/src/../py/main-gdb.py')

The correct thing to do is never call normpath; instead leave .. components and pop off the last element after ensuring that the preceding directory is not a symlink.

This bug seems pretty severe to me, because it prevents imports from working.

Exact python --version and Debian package versions:
Python 2.6.7    (2.6.7-4)
Python 2.7.3rc2 (2.7.3~rc2-2.1)
Python 3.2.3    (3.2.3-1)
msg164092 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-06-26 19:53
Is this a duplicate of issue 6975, or something different?

2.6 only gets security patches.  (We use the version field to show what version we need to apply the fix to.)
msg164093 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-06-26 20:08
Indeed, this is pretty bad behaviour, especially for realpath(). Both abspath() and normpath() should never be called before any symlinks are resolved.

Of course, fixing it as a bug means it could break existing code which relies on ".." fragments being folded.
msg164110 - (view) Author: Ben Longbons (o11c) * Date: 2012-06-26 21:23
Yeah, this is a duplicate of issue 6975.

Sorry also about the version thing.

Although I can set this as closed: duplicate, I don't seem to be able to set what bug this is a duplicate of.
History
Date User Action Args
2012-06-26 21:36:13r.david.murraysetsuperseder: symlinks incorrectly resolved on POSIX platforms
2012-06-26 21:23:29o11csetstatus: open -> closed
type: behavior
resolution: duplicate
messages: + msg164110
2012-06-26 20:08:55pitrousetpriority: normal -> high

nosy: + hynek, pitrou
messages: + msg164093

stage: needs patch
2012-06-26 19:53:43r.david.murraysetnosy: + r.david.murray

messages: + msg164092
versions: + Python 3.3, - Python 2.6
2012-06-26 19:04:01o11ccreate