3 ms·
Punchline: > My tarball happened to contain over 800 000 links with ".." as a path component. It also happened to contain over 5.4 million hard links. The beh
by kentonv 4y ago
Punchline:
> My tarball happened to contain over 800 000 links with ".." as a path component. It also happened to contain over 5.4 million hard links.
The behavior is more precisely described not as quadratic, but O(n*m), where n is the number of symlinks pointing outside of the extraction directory, and m is the number of hardlinks. It happens because of the security precautions gnu tar performs to make sure a malicious archive can't set up a symlink pointing to an arbitrary place in your filesystem, and then extract files to it. The strategy they use has an unoptimized corner case when the archive also has a lot of hardlinks.
The mechanism could probably be improved by remembering the list of deferred symlinks in a hash map rather than a linked list, but also, both symlinks pointing outside the extraction directory, and hardlinks, are uncommon.
(Edited to correct: The problem exists even if the hardlinks do not actually point at the symlinks.)
- romwell 4y agoYup, and that's worst-case quadratic in number of links (symlinks and hardlinks). It's still weird they didn't do a hashmap.
- account42 4y agoIt's C and they probably never thought of anyone having a file with that many links.
- mort96 4y agoTo clarify, the problem doesn't only exist with symlinks pointing outside of the extraction directory. The problem exists if the symlink's target path is a relative directory which contains "..". That means a symlink at "somedir/subdir1/foo" which points to "../bar" will also use the delayed link mechanism, even though the symlink doesn't point to outside of the extraction directory. Relative symlinks which contain ".." are incredibly common in some contexts.