On Mon, Apr 27, 2015 at 08:12:42PM +0100, Nick wrote: > 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
I am not sure what the proper approach is. Option 3) sounds pretty safe as a starting point. Any ideas?
