Re: [Bug-tar] [PATCH] Option to treat tarbombs as errors

[Hugo . Mildenberger]

On Wed, 27 Nov 2013 18:58:03 -0800
Connor Behan <address@hidden> wrote:

> On 27/11/13 08:25 AM, Joshua Hudson wrote:
> > It is my opinion this patch is incorrect in design.
> >
> > If I were to arrange for the first file to be .bashrc, you would get the 
> > error, but the damage would already be done.
> Good point. The patch prevents the clutter of a tarbomb but it wouldn't
> be able to save this first file.
> > What would be immediately beneficial is a patch that provides option if 
> > given tar -xf filename.tar*, ensuring
> > that all paths begin with filename/, and prepending filename/ if they 
> > don't. Do mkdir filename first for the obvious reason.
> You might be interested in and earlier version of the patch:
> http://lists.gnu.org/archive/html/bug-tar/2013-08/msg00031.html
> 
> Paul said a simpler patch that just causes an error would be preferable
> but so far neither version has been accepted. It all depends on what
> Sergey says if / when he looks at this. I'll post an updated version
> that prepends filename/ and then try to ping the maintainers.
> 

Connor,

prepending the package name (if the directory does not yet exist) would also 
cope with 
archives containing top level "." entries. Such packages are common because 
some developers 
have the habit to create new releases by issuing a command similar to the 
following:

  $ cd ~/package-xyz-1.0  && tar -cf /tmp/package-xyz-1.0.tar .

Now, if you're using a source distribution, such an archive may get 
automatically extracted within
a privileged process. In the particular case I observed some time ago, 
unpacking the sources was 
roughly done like

  # P=package-xyz-1.0 && mkdir -p "/tmp/${P}/work" && tar -C "/tmp/${P}/work" 
-xf "/tmp/${P}.tar"

The next step was to set the access rights *within* the newly created work 
directory. But because 
the tar archive contained 

  drwxr-xr-x 7121/7121         0 2013-11-28 14:12 ./
  -rw-r--r-- 7121/7121         0 2013-11-28 14:12 ./some-file.txt

with the "./" entry denoting the current directory, the newly created work 
directory was 
still owned by the package author, and not by the privileged user who created 
the work directory:

 $ ls -ld /tmp/package-xyz-1.0/work
 drwxr-xr-x 2 7121 7121 4096 28. Nov 14:12 /tmp/package-xyz-1.0/work

While tar behaved correctly here, this certainly was a defect of the 
distribution (Gentoo 
in this case). Yet it can also be seen as unexpected behaviour.


Best regards

Hugo Mildenberger

--