Bug 76049 - 'cd' builtin to bash improperly traverses pathnames containing both symlinks and '..'
'cd' builtin to bash improperly traverses pathnames containing both symlinks ...
Status: CLOSED DUPLICATE of bug 72363
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-10-16 02:11 EDT by Jeff Stearns
Modified: 2007-04-18 12:47 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-16 02:11:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Stearns 2002-10-16 02:11:16 EDT
From Bugzilla Helper:

User-Agent: Mozilla/4.0 (compatible; MSIE 5.22; Mac_PowerPC)

Description of problem:

The 'cd' command improperly traverses pathnames containing both symlinks and '..'.

A pathname containing '..' is improperly traversed when one element of the pathname is 
a symbolic link to a directory.

The symlink is treated completely WRONG; it is handled as though it had a value of '.'. 

This affects the cd command in bash. It also affects make(1) and other tools that call 
bash. It also affects system(3).

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:

1.Create a simple directory hierarchy containing a symlink:

    % mkdir -p  /tmp/0/1/2/3/4

    % cd  /tmp/0/1/2/3/4

    % ln -s .. up

2. Navigate to the directory containing the symlink:

    % cd  /tmp/0/1/2/3/4

3. Use the cd command to navigate via the symlink.  Note that the following is correct:

    % (cd up; pwd; ls)




4. Now traverse via a pathname combining the symlink with '..'.  Note that the traversal is 
now WRONG.

    % (cd up/..; pwd; ls)



Actual Results:  The pwd command in step 4 printed:


The ls command printed:


Expected Results:  The pwd command in step 4 should have printed:

    /tmp/0/1/2  or /tmp/0/1/2/3/4up/..

The ls command should have printed:


Additional info:

The bug is in bash, but not in the kernel itself.  You can prove this by writing a C, perl, or 
Python program to call chdir(2) and observe that the behavior is correct.

It appears that bash is interpreting pathnames itself, and is doing it wrong. It appears to 
be pre-parsing pathnames, performing '..' reduction on its own. It's doing this wrong. It's 
treating symlinks as directory names, rather than traversing them.
Comment 1 Tim Waugh 2002-10-16 03:42:56 EDT
As documented.  Use 'set -P' to disable that.

*** This bug has been marked as a duplicate of 72363 ***

Note You need to log in before you can comment on or make changes to this bug.