Re: Tar problem

On Fri, May 21, 2004 at 12:10:39PM -0700, Tim Kientzle wrote:
> Pete Carah wrote:
> >When I unpack the ports collection, the symlink 
> >has been overwritten with the real directory
> 
> This is deliberate; bsdtar does essentially the
> same thing.
> 
> With bsdtar, -P will prevent this behavior.
> (In bsdtar, -P means "leave my (P)athnames alone, damnit!" ;-)
> 
> I don't know if there's any way to prevent this
> behavior with gtar.

....
 
> o  Archive entries can have absolute pathnames.  By default, bsdtar
>    removes the leading / character from filenames before restoring
>    them to gaurd against this problem.
> 
> o  Archive entries can have pathnames that include .. components.
>    By default, bsdtar will not extract files containing .. compo-
>    nents in their pathname.
> 
> o  Archive entries can exploit symbolic links to restore files to
>    other directories.  An archive can restore a symbolic link to
>    another directory, then use that link to restore a file into
>    that directory.  To gaurd against this, bsdtar checks each
>    extracted path for symlinks.  If the final path element is a
>    symlink, it will be removed and replaced with the archive
>    entry.  If -U is specified, any intermediate symlink will
>    also be unconditionally removed.  If neither -U nor -P is
>    specified, bsdtar will refuse to extract the entry.
> 
...

GNU tar didn't do this a year or two ago...  POLA to me would be to honor a preexisting
top-level symlink.  And I may well want to accomplish the 2nd and 3rd (e.g. restore a 
complete system image with symlinks containing .. chars...) (ln -s ../netscape-6/netscape
netscape in /usr/local/bin, for example...  I'd want to preserve this rather than either of
the things mentioned above.)  symlinks pointing to dirs and symlinks pointing to files
are qualitatively different, too, even though stat() doesn't treat them differently.

Also note that my complaint involves NONE of these; the ports collection archive contains
no symlinks.  The symlink preexists and moves only the top-level directory...
(in other words, I'm being caught by a side-effect of their paranoia - they remove
symlinks after restoring them rather than spotting them and refusing to restore them;
the latter behavior would still work in my case.)

I know how to work around it in this case, but it can be painful in cases where 
I want to split where an archive restores to.

The only completely secure way around this particular problem is to remove symlinks 
from the system entirely; I remember some netnews discussions about this 10-15 years 
ago (a thread whose name resembles "symlinks are a botch"... (1987 - dejanews can be handy))  
In the netscape case above, one could in principle use a hardlink.  However, that doesn't 
tell the admin just where the link target is and why it's there.  And tar doesn't always
handle hardlinks right either...  (e.g. - a hardlink on the source system which crosses
a filesystem boundary on the target.  What tar does here is restore multiple copies.  
A sysadmin would usually apply a symlink here instead...)

Eventually *any* flexible-enough system comes back and bites someone.  Does that mean 
systems shouldn't be flexible?   This applies to *many* things besides computers.
(does the existence of traffic accidents or even intentional misuse of cars, both of
which exist, mean we should ban cars?  If you read the legal literature, this problem
has a *very* old history (many centuries) and no general solution).  (and even security
measures meant to counter these problems often fall in the class of biting back!!!)
Not that I'm saying not to try; the internet is chaotic enough as it is and I spend
much of my time dealing with security matters many of which arise from too-general
or too-open solutions to problems.

Here, all I'm saying is that bsdtar's -P should exist; the default security solution 
should address the complaints specifically, though, and not extend too much beyond 
them as this one appears to.  And the gtar behavior changed from historical without 
explanation or notice...  (this behavior doesn't show in either the (unofficial) man 
page or the (more official) info, nor does (of course) any indication of an exception 
option.)  I'm trying -P, which is documented to do something else (though also part
of bsdtar's -P) - for our system gtar, this has no effect on the behavior in question. 
I'd even say that changes of this kind should show in UPDATING, though neither the
posix change to sort nor this change to tar did (and the sort change was backed out)
since both affect many sysadmin scripts...

-- Pete