| Summary: | tar cannot handle names that are exactly 100 chars | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | Frans Meulenbroeks <fransmeulenbroeks> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | enhancement | CC: | busybox-cvs, vda.linux |
| Priority: | P5 | ||
| Version: | 1.13.x | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
The code is:
if (!p_longname && parse_names) {
/* we trash mode[0] here, it's ok */
//tar.name[sizeof(tar.name)] = '\0'; - gcc 4.3.0 would complain
tar.mode[0] = '\0';
if (tar.prefix[0]) {
/* and padding[0] */
//tar.prefix[sizeof(tar.prefix)] = '\0';
tar.padding[0] = '\0';
file_header->name = concat_path_file(tar.prefix, tar.name);
} else
file_header->name = xstrdup(tar.name);
}
Note how tar.mode[0] = '\0' inserts terminating NUL, thus xstrdup will stop at 100th char.
I also tried to reproduce it and successfully tarred and untarred a file with a 100-characher filename.
Please attach a tar file which unpacks incorrectly with busybox tar.
|
confirmed in 1.13.2: tar cannot handle filenames that are exactly 100 characters. It creates an entry of the normal type (so no gnu long extension), and the name header field is completely filled. When extracting such a file, the name is copied with strdup, but as there is no 0 byte after the name, the rights are also copied, resulting in a file that e.g. ends in 000644. Fix is probably in get_header_tar.c after line 254: file_header->name = xstrdup(tar.name); add a statement like: if (strlen(file_header->name) > 100) file_header->name[100] = 0; but there might be a better solution.