Re: Problem with tarfs ?

[Pavel Roskin <proski gnu org>]

On Sun, 26 Oct 2003, Pavel Roskin wrote:

> Confirmed.  Either my implementation of vfs_s_fullpath() for archives is
> incorrect, or there is an unrelated bug.  The entry corresponding to
> "cc1.exe" has its parent set to an entry called "..", which I didn't
> expect to happen.  I believe the link from inodes to entries was an
> afterthought and wasn't implemented properly, at least for tar archives.
> Unfortunately, changing undocumented code is very dangerous.

The bug has been fixed by removing vfs_s_add_dots() and code that attempts
to do the same.  The "." and ".." entries could make the cached tree
non-traversable from an inode up to the root.

This is not a problem without relative symlinks because the upper level of
VFS would always present the full path to the low-level code.  However, a
relative symlink needs to be resolved by the low-level code, which
requires walking the tree towards its root (or preserving full path
across all calls and some insane operations that had buffer overflows).

Adding "." and ".." to the tree would replace the links from directory
inodes to the entries with the new dummy entries.  Of course, I could have
put protection to vfs_s_new_entry() not to replace entry->ino->ent if it's
set (I think I'll do it shortly anyways).  But the code for adding dots
was so ugly and full of FIXMEs so I just removed it.

mc already knows that it should add "." and ".." if they are missing.  If
correctness of VFS is desired, support for "." and ".." will be restored.
But in the meantime it's important to keep VFS in a good shape.  It's a
shame that known security problems take more than a month to get fixed
because of the code is so hard to understand.

-- 
Regards,
Pavel Roskin