I have a coworker who says you need to be careful extracting tarballs because they can make changes you don't know about. I always thought a tarball was just a hierarchy of compressed files, so if you extract it to /tmp/example/ it can't possibly sneak a file into /etc/ or anything like that.

  • 1
    What Operating System environment(s) are you concerned with? GNU/Linux's tar has a -P option that influences its behavior in this regard. – Jeff Schaller Aug 30 at 13:22
  • 1
    I guess CentOS in this case, but I'd like to know whatever I should know. – Adam R. Grey Aug 30 at 13:28
  • 1
    For a longer time, GNU tar could be fooled in a way that allowed to make it e.g. remove /etc/passwd in case it was run as root. Since a while, I believe that gtar gives similar security as you get with star. – schily Aug 30 at 13:36
up vote 40 down vote accepted

Different tar utilities behave differently in this regard, so it's good to be careful. For a tar file that you didn't create, always list the table of contents before extracting it.

Solaris tar:

The named files are extracted from the tarfile and written to the directory specified in the tarfile, relative to the current directory. Use the relative path names of files and directories to be extracted.

Absolute path names contained in the tar archive are unpacked using the absolute path names, that is, the leading forward slash (/) is not stripped off.

In the case of a tar file with full (absolute) path names, such as:

/tmp/real-file
/etc/sneaky-file-here

... if you extract such a file, you'll end up with both files.

GNU tar:

By default, GNU tar drops a leading / on input or output, and complains about file names containing a .. component. There is an option that turns off this behavior:

--absolute-names

-P

Do not strip leading slashes from file names, and permit file names containing a .. file name component.

... if you extract a fully-pathed tar file using GNU tar without using the -P option, it will tell you:

tar: Removing leading / from member names

and will extract the file into subdirectories of your current directory.

AIX tar:

says nothing about it, and behaves as the Solaris tar -- it will create and extract tar files with full/absolute path names.

HP-UX tar: (better online reference welcomed)

WARNINGS

There is no way to restore an absolute path name to a relative position.

OpenBSD tar:

-P

Do not strip leading slashes (/) from pathnames. The default is to strip leading slashes.

There are -P options implemented for tar on macOS, FreeBSD and NetBSD as well, with the same semantics, with the addition that tar on FreeBSD and macOS will "refuse to extract archive entries whose pathnames contain .. or whose target directory would be altered by a symlink" without -P.

schilytools star:

-/

Don't strip leading slashes from file names when extracting an archive. Tar archives containing absolute pathnames are usually a bad idea. With other tar implementations, they may possibly never be extracted without clobbering existing files. Star for that reason, by default strips leading slashes from filenames when in extract mode.

  • 2
    For a long time, GNU tar ignored the fact that a path name containing .. is a security risk, so use star or a recent gtar. Also have a look at the star example tar archives that include hand crafted tar headers that cause most tar implementations to remove files without even a warning. – schily Aug 30 at 13:59
  • @schily, according to Jeff's quotes, doesn't that apply to tar on Solaris, AIX and HP-UX, too? If so, why point out only GNU tar, especially if (again according to the quote above), they've changed to not accepting ..? Issues with malformed input are of course bugs, and I suppose you've reported them as such. – ilkkachu Aug 30 at 16:07
  • 1
    Historic tar implementations are not checking things like that. I needed to make the remark because there was the claim that GNU tar is without problems without mentioning a release. And BTW: a list like this without mentioning star (the oldest free implementation) must be seen as incomplete. – schily Aug 30 at 16:41
  • @schily, I searched for man pages for major OS's (that may have different tar implementations); if you have a link to star's online man page, I'd be happy to include it. – Jeff Schaller Aug 30 at 16:42
  • 2

One of the hilarious things that happen with tar bombs is that they change the permissions of the current directory to the one included in the tarball.

For instance, if a tarball includes the '.' directory, and you unpack it in /tmp as root, it will wreck your system by making the /tmp unwritable by anybody but root.

  • And if you unpack it in /, it will change the permissions of the root directory, which will have unexpected consequences (I remember getting "cannot execute /bin/bash" when logging in on a console, because / was mode 770). – Law29 Aug 31 at 10:47
  • 1
    I've had this happen with official software - the github releases of "rancher-compose" all contain "." in the tar file, for example, and nuke /tmp if you extract them there. – Harald Sep 3 at 17:41

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.