On Wed, 28 May 2008 12:29:46 +0100 Ian Jackson <ian.jack...@eu.citrix.com>
wrote:
> lstat64("./test\\_file_with_^Hackslashes_in_name", 0xff9bb98c) = -1 ENOENT
> (No such file or directory)$
> write(2, "./test\\\\_file_with_\\backslashes_"..., 52) = 52$
> mariner:d>
>
> ?!?!
>
> This is probably a security problem in some circumstances, but I can't
> think of an exploit offhand so I've set the severity only to `important'
> rather than the `grave' that might be appropriate.
>
> When we have a fix it should almost certainly be backported to etch.
> Surely no-one can be relying on this insane behaviour.As surprising as the behavior seems to you, it is the documented behavior of GNU tar. See this page, for example, which explicitly mentions \b as an escape sequence that is unquoted by default: http://www.gnu.org/software/tar/manual/html_section/Selecting-Archive-Members.html You can get the behavior you would like instead by passing the --no-unquote option. I hope that helps, -Carl PS. Bdale, for a case like this should I close the bug report by sending to 483358-done@ ? And should I give it a "Tags: wontfix" or so?
signature.asc
Description: This is a digitally signed message part
