Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

bos opened this issue May 24, 2012 · 1 comment

Comments

@bos
Copy link
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.

@bos
Copy link
Contributor Author

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 as completed May 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant