Applied, thanks! Sorry for the delay :/
On Tue, May 1, 2018 at 7:30 AM, Harald van Dijk <har...@gigawatt.nl> wrote: > ping^2 > > On 4/15/18 8:25 PM, Harald van Dijk wrote: >> >> ping >> >> FWIW, this problem actually came up with an archive containing a fsroot >> including a busybox installation again, but this time, the archive was >> created after a deduplication step had hardlinked identical files and >> symlinks. >> >> On 4/1/18 1:37 PM, Harald van Dijk wrote: >>> >>> When the creation of symlinks got delayed until after all other files had >>> been extracted, that didn't take into account that the archive may contain >>> hardlinks to those symlinks. The extraction of those hardlinks did not get >>> delayed so would fail. >>> >>> This patch generalises the symlink_placeholders approach to a >>> link_placeholders which allows delaying the extraction of hardlinks too. It >>> changes the order in which delayed links are added to ensure that a hardlink >>> to an earlier symlink will create the symlink first. >>> >>> It delays all hardlinks without regards to the target. It may be >>> desirable to instead tweak it to determine whether the link target is a >>> delayed symlink, but that is a cost/benefits tradeoff. As hardlinks are >>> relatively rare, I guess the benefit of such an optimisation would be small, >>> but I am not really qualified to make that determination. >>> >>> Test case: >>> >>> mkdir dir >>> >dir/a >>> ln -s ../dir/a dir/b >>> ln dir/b dir/c >>> mkdir new >>> tar cf - dir/* | tar -C new -xf - >>> >>> busybox ad4e9613: >>> >>> tar: can't create hardlink 'dir/c' to 'dir/b': No such file or directory >>> >>> busybox ad4e9613 + patch: >>> >>> No error output. The archive is successfully extracted. >>> >>> The security hole that the delayed extraction of symlinks was meant to >>> prevent should not be re-introduced by the delayed creation of hardlinks: >>> the parent components of archive entries still get created first, so if an >>> archive contains a file "exploit", a symlink "parent -> ..", and a hardlink >>> "parent/exploit -> exploit", the presence of that hardlink causes "parent" >>> to be immediately created as a regular directory. The symlink creation >>> "parent -> .." will therefore fail. This could use careful review though. >>> >>> Cheers, >>> Harald van Dijk > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
