Date: Fri, 21 May 2004 14:17:13 -0700 From: Pete Carah <pete@altadena.net> To: Tim Kientzle <kientzle@freebsd.org> Cc: current@freebsd.org Subject: Re: Tar problem Message-ID: <20040521211712.GA80346@users.altadena.net> In-Reply-To: <40AE542F.1060905@freebsd.org> References: <20040521180520.GA79342@users.altadena.net> <40AE542F.1060905@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040521211712.GA80346>