Quoth Nick: > Quoth Dimitris Papastamos: > > Some things that need to be done for tar: > > > > ... > > - Strip leading / from filenames and dangerous things like ../../ etc. > > OK, attached is a patch that does that. I think it covers all the > bases.
One thing the patch doesn't cover is an archive using a symlink to somewhere like ../../ and then putting a file in symlink/newfile (hence sending it to ../../newfile). I only thought of that when reading the bsdtar manpage[0]. I'm not sure what the best behaviour is in that case. Some options: 1) If a symlink creates a path ascending further up the directory tree (towards /) than the current directory, replace all symlinks in the path with directories and extract there. 2) Remove the symlink and replace it with a real directory before extracting the file into it (this is the behaviour of bsdtar with the -U option) 3) Refuse to create any file following a symlink (this is the default behaviour of bsdtar) 4) Issue a warning if writing a file, but follow the symlink as instructed If you're curious about how bsdtar does it, look at check_symlinks() in libarchive/archive_write_disk_posix.c, but note the comment at the top of the function - "TODO: Make this work." I have a slight preference for option 1, but it doesn't feel particularly clean. Anyone else have better ideas? I know it's annoying, but I don't think "ignore it" is good enough, as it would be far too easy to create a tarball that blatted any file the user had access to using this method (and using -t to check paths wouldn't help, as the ../ is in the symlink target). I'm attaching a tarball that demonstrates the problem, in case I haven't explained it well enough. If you used $HOME/bin/, and unpacked the tarball in $HOME/tmp, it will create a file in $HOME/bin/myscript. Nick 0. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/bsdtar.1.html
test.tar
Description: Unix tar archive
signature.asc
Description: Digital signature