cabal-install's tar unpacking does not cope well with links #239

Closed
bos opened this Issue May 24, 2012 · 1 comment

Comments

Projects
None yet
1 participant
Contributor

bos commented May 24, 2012

(Imported from Trac #246, reported by @dcoutts on 2008-02-22)

Extracting /home/me/.cabal/packages/hackage.haskell.org/pandoc/0.46/pandoc-0.46.tar.gz to /tmp/TMPpandoc-0.46...
cabal: /tmp/TMPpandoc-0.46/pandoc-0.46/COPYRIGHT: copyFile: does not exist (No such file or directory)
If we look at this tarfile we find that the COPYRIGHT entry in the tar file is actually a symbolic link to debian/copyright. The tar code in cabal-install is designed to cope with symbolic links. It handles them by copying the target file. Same goes for hard links. The problem in this case is that it is trying to copy the other file before it has been unpacked.

One partial solution would be to accumulate a list of links and then copy all at the end after the other files have been unpacked. It's only partial because someone could make a tarball with links pointing to other links. We can probably just ignore that problem and let it fail in the same way it does now.

Contributor

bos commented May 24, 2012

(Imported comment by @kolmodin on 2008-02-22)

Tue Mar  4 20:42:55 CET 2008  Lennart Kolmodin <kolmodin@gentoo.org>
- Fix defect when unpacking tar files containing links
  There were two issues;

```
* Unpacking links that point to files not yet unpacked
* Used the link target as absolute path, but it's relative
```

  This patch addresses both issues, which is ticket #246.
  There may still be errors if a link refer to another link which has not
  been unpacked yet.
We should think of sanity (and security) too, what if a link points outside the working directory?

@bos bos closed this May 24, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment