[PATCH v2] tar: regression with hardlinked symlinks

[Harald van Dijk]

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