Re: -current tar(1) breakage

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

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.

Yes, we expect the OS to return something reasonable in those cases,
but we can sanity check the values we compute (for buffers) so that
the program does not crash. An assertion in this case would have
saved a lot of debugging time.

christos