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
Received on Mon Apr 27 2015 - 21:12:42 CEST