#2544 Absolute pathnames with ../ and links

obsolete: 8.4.5
open-fixed
Vince Darley
7
2004-12-02
2003-11-26
Christoph Fuchs
No

This concerns Tcl on Unix (Solaris 8, Solaris 9, RH
Linux Kernel 2.4.?):

When trying to open a file (e.g. [open $filename r])
with an absolute pathname containing symbolic links and
../ (parent directory), a wrong file is referenced:
e.g. if /home/somedir is a link to /root/otherdir then
trying to open /home/somedir/../file opens /home/file
instead of /root/file

In Tcl 8.3.1 open worked as expected. The first Tcl
version which I can test and has the problem is 8.4.1

Discussion

  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-11-26

    • status: open --> closed-out-of-date
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-11-26

    Logged In: YES
    user_id=72656

    This works for me in 8.4.5 on linux:

    ln -s /tmp/dist /home/
    tclsh
    % open /home/dist/../jeffh/.cshrc
    file4

    So this should have been checked against the latest release
    before submitting.

     
    • status: closed-out-of-date --> open
     
  • Logged In: YES
    user_id=917954

    The bug IS still ion 8.4.5. What I wanted to say that it
    probably first occured between 8.3.1 and 8.4.1.

    In your example /home/dist is a link to /tmp/dist
    So /home/dist/../jeffh/.cshrc is /tmp/jeffh/.cshrc, not
    /home/jeffh/.cshrc (try it e.g. with ls in any shell).
    However, as long as you do not have a file
    /tmp/jeffh/.cshrc, the open command from your example should
    return an error "no such file or directory", instead of
    opening the wrong file.

    The same behaviour can also be found with a non-existing
    directory in your pathname:
    open /home/jeffh/nonexistentdir/../.cshrc
    fails in 8.3.1 (correct), but succeeds in 8.4.5 (incorrect)

     
  • Vince Darley
    Vince Darley
    2003-12-10

    Logged In: YES
    user_id=32170

    This behaviour is all down to 'file normalize', so if this
    bug report is correct, you should be able to show that 'file
    normalize' returns the wrong path for some input strings
    containing ../

    Can you please try to provide one or two examples?

     
  • Vince Darley
    Vince Darley
    2003-12-10

    Logged In: YES
    user_id=32170

    Here's a simple example on Windows:

    file mkdir tclfoo
    cd tclfoo

    file mkdir one/two/three
    file link link one/two/three
    file normalize link/../foo

    # The result:
    E:/tclfoo/foo
    # It should be:
    E:/tclfoo/one/two/foo

     
  • Vince Darley
    Vince Darley
    2003-12-10

    • priority: 5 --> 7
     
  • Vince Darley
    Vince Darley
    2003-12-10

    Logged In: YES
    user_id=32170

    The bug is quite clear now. TclFSNormalizeAbsolutePath
    removes all '.' and '..' sequences before passing the path
    to the platform-specific normalization code. But, the '..'
    removal is done in a purely string-based way, with no
    awareness of symlinks at all.

    We probably need to remove that whole block of code (lines
    149-173 of tclPathObj.c) and make each platform-specific
    piece of code a bit cleverer.

    This might actually improve performance, since it would
    remove the need for a whole file split/file join pair in the
    current approach (but replace it with more complex
    platform-specific code).

     
  • Vince Darley
    Vince Darley
    2003-12-10

    Logged In: YES
    user_id=32170

    Please test the attached patch (to Tcl 8.5a0)

     
  • Vince Darley
    Vince Darley
    2003-12-11

    • assigned_to: vincentdarley --> hobbs
     
  • Vince Darley
    Vince Darley
    2003-12-11

    Logged In: YES
    user_id=32170

    Updated patch. Needs testing on unix, but should then be
    ready to go.

    Jeff: could you test this please?

     
  • Vince Darley
    Vince Darley
    2003-12-12

    diff -u with windows eols

     
    Attachments
  • Vince Darley
    Vince Darley
    2003-12-12

    Logged In: YES
    user_id=32170

    Updated patch for cvs head.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-06

    Logged In: YES
    user_id=72656

    We will also need an 8.4-based patch.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-06

    • priority: 7 --> 9
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-18

    Logged In: YES
    user_id=72656

    backported for 8.4.6.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-18

    • status: open --> closed-fixed
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-18

    Logged In: YES
    user_id=72656

    had to revert because the changes were not properly
    isolated, and the 8.5 changes are a lot more spread out than
    expected. Don't know quite what to backport ...

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-02-18

    • status: closed-fixed --> open-fixed
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2004-11-17

    • assigned_to: hobbs --> vincentdarley
     
  • Don Porter
    Don Porter
    2004-11-17

    Logged In: YES
    user_id=80530

    This matter is related to 961646.

    Both are rooted in the fact that
    Tcl's Tcl_Filesystem layer is
    imposing one interpretation of
    ".." in a path instead of leaving
    it up to each (native) filesystem
    to use its own preferences.

     
  • Don Porter
    Don Porter
    2004-12-02

    Logged In: YES
    user_id=80530

    dropping priority since this
    can't be "fixed" until the
    differences of opinion about
    the correct design of the
    VFS layer laid out in 961646
    are addressed.

    this won't be fixed in Tcl 8.4.9.

     
  • Don Porter
    Don Porter
    2004-12-02

    • priority: 9 --> 7
     
  • Vince Darley
    Vince Darley
    2004-12-02

    Logged In: YES
    user_id=32170

    I don't know if I agree with dgp's comment that each
    filesystem should have its own interpretation of '..'.
    Surely they should be the same? (At least that's what's in
    Tcl 8.5)