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
use).

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 <tv@pobox.com>