On Wed, 27 Nov 2013 18:58:03 -0800 Connor Behan <connor.be...@gmail.com> 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 --
