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)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2002-10-16 02:11:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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:

Always



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)

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

    4

	

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



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

    /tmp/0/1/2/3/4

    up



Actual Results:  The pwd command in step 4 printed:

    /tmp/0/1/2/3/4



The ls command printed:

    up



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:

    3/



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.