search

fox-it / dissect.target

The Dissect module tying all other Dissect modules together. It provides a programming API and command line tools which allow easy access to various data sources inside disk images or file collections (a.k.a. targets).
GNU Affero General Public License v3.0
43 stars 44 forks source link

Bug in plocate plugin #696

Closed jadevries closed 4 months ago

jadevries commented 5 months ago

Using the plocate file parser class outside of the Dissect context I noticed a bug: (almost) every 32nd path gets appended to the previous path. While testing with target-query I also could reproduce this behaviour on Debian, Ubuntu and Fedora.

I tested and reproduced this on: Fedora 39: python 3.12.0 (plocate 1.1.17) Fedora 40: python 3.12.2 & python 3.9.19 (plocate 1.1.22) Ubuntu 11.04: python 3.10.12 (plocate 1.1.15) Debian 11: python 3.9.2 (plocate 1.1.8-2)

plugin function used: https://github.com/fox-it/dissect.target/blob/b1bcb0d89d3b24a9ad7e8150d63ddd6dd30a82a2/dissect/target/plugins/os/unix/locate/plocate.py#L138C21-L138C26

Horofic commented 5 months ago

@JSCU-CNI Have you noticed any similar behaviour on your side? This behaviour does not seem to occur in the related test-cases.

JSCU-CNI commented 4 months ago

Thank you for the fix @Horofic. This seems like an oversight from our end. It is not clear to us as to why the end of a zstd frame does not contain a final null byte. Could that be a bug in plocate's zstd implementation? Reading in chunks and splitting on null bytes seems like a reasonable fix to us for now.

Schamper commented 4 months ago

I have not looked at any plocate code, but I can imagine it's a small optimisation if the decompressed data fits entirely within one frame, otherwise you'd have to move the final path to the next frame just to fit the null byte. Especially if you then decompress into a char[FRAME_SIZE + 1] it shouldn't give you any trouble in C.