Subject: Re: tar ignores filenames that contain `..'
To: Frederick Bruckman <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 10/23/2002 16:35:25
On Wed, 23 Oct 2002, Frederick Bruckman wrote:
: > Why not just have an '--allow-dot-dot' flag or something similarly
: > (in)sane added to pax? That way you have to explicitly say that
: > 'yes, I *know* there are ../ entries in here. Do It Anyway.'
: There already is one (--insecure).
Ick. That doesn't really help much, since an admin would have to use such a
flag on any pax-based backup-and-restore. (Think "already written
backup/restore helper scripts".) For instance, there's dozens of symlinks
on my system containing "../", none of which would come back to me if I
were to extract with the "new" pax
Seems to me like cutting off all blood flow to an arm because it's cut.
I don't run -current right now, so I'm curious as to whether such a symlink
will be skipped on a "pax -rw", where yuou're just wanting to move a whole
tree...? This is, of course, a completely normal operation that could
easily contain symlinks in the middle with "../" in their contents.
: Note that if you add the flag to the package tools invocation, then you
: have to require current "pax"..., only to get the old behavior!
I'm tempted to have a go at the 4-step version I posted earlier--which, if
you look carefully, says nothing at all about symlinks containing "../",
because that fact isn't relevant. Hence, even pkg_* and backup/restore
scenarios can use a pax, so modified, just fine without warnings or errors
(all three listed scenarios are corner cases that shouldn't happen in normal
The plan I posted does invert the security logic, though, which jives with
most commands with which I'm familiar. (Default == work but with warnings;
one flag turns warnings into errors; another optional flag can suppress the
warnings.) This would mean adding the invocation in pkg_* to use the "safe"
flag if that mode were desired, as I believe it would.
But what I don't necessarily have in the very near term is the time to
commit to implementing and testing it all.
-- Todd Vierling <firstname.lastname@example.org>