Re: Tar extract behaviour changed

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 21 Oct 2019 21:20:25 +0200
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20191021192025.GA33725%bec.de@localhost>

  | That said, I don't really see a point in
  | allowing one form of arbitrary file replacement and not another.

If we're thinking of it purely as protection against potentially
malicious archives obtained from some random internet site, then
nor do I - but that's a case where you don't really want to allow
any of this, with the possible exception of symlinks: If I have
deliberately set up a bunch of symlinks to direct parts of the extracted
file tree to different mounted filesystems (if I don't have space to
extract it all into one, and then move parts later, or simply don't
want to waste the time doing that if it is a very big data set) then
following my carefully positioned symlinks is not an issue -- as long
as we're still not allowing .. or / the extraction must remain within
my otherwise empty target tree, so the only existing symlinks it can
see are the ones I deliberately placed there).

But if instead we're considering an archive I created a few years back
when I was short on space, and had a large collection of highly compressible
files I wasn't likely to need any time soon, but needed the space in a
hurry, so wasn't all that careful when creating the archive, then things
are different.

Now, when I need the files to exist again, I can find the space, but not
in the same places as before, so I want it to follow symlinks, I still
want to extract the files I archives using ../filename (when I wasn't
in the correct parent directory for everything when I made the archive)
but I don't want to put the few files archived using full pathnames
back into those names, so I want the leading '/' removed, so I can still
extract those few files, after which I will move them to where they now
belong.

I don't see a problem with a default -P to override all of the checks
(even if it is different than what we had before) but I can certainly
see a use for specific options for each of them, because there can always
be situations where one is wanted and another is not.

On the other hand, all that said, I personally have no such weird
archives that I'm aware of, so I'm not likely to spend the time any time
soon to make this happen (not that it should really be very difficult, it
is mostly just option parsing and then testing the correct (different)
option state in each of the cases rather than just a single "insecure"
option).

kre