Re: -current tar(1) breakage

[christos%astron.com@localhost (Christos Zoulas)]

In article <YGjWJlaPo2rtvMqq%bec.de@localhost>, Joerg Sonnenberger  <joerg%bec.de@localhost> wrote:
>On Sat, Apr 03, 2021 at 08:14:34PM -0000, Christos Zoulas wrote:
>> In article <YGiV7Tup4jYZ9QdO%bec.de@localhost>, Joerg Sonnenberger 
><joerg%bec.de@localhost> wrote:
>> >On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote:
>> >> Yes, I think that the appropriate change is to make those assertions
>> >> so if there is a broken filesystem/syscall there is a more obvious
>> >> error (rather than infinite loop in read or core-dump in iconv), but let's
>> >> see what joerg thinks about all that.
>> >
>> >The infinite loops are perfectly reasonable behavior for broken kernel
>> >input and found in other tools using the interface. IMO the kernel
>> >should always do a sanity cap for puffs/fuse here.
>> 
>> Yes, but defensive programming is good.
>> 
>> >The iconv coredump is a buffer overflow, but nothing libarchive can do
>> >about. The memory allocated for the dirent is based on the namemax of
>> >the filesystem and we kind of have to trust the filesystem to do what it
>> >promised. The system call doesn't have a size argument...
>> 
>> Right, but it can check if the size makes sense before using it.
>
>The next filesystem will put one in the field and we are back...

There is a difference between sub-optimal performance and core-dumping
or infinite-looping.

christos