Skip to content

tracker-extract: Turn off security features under Valgrind

The introduction of our multiple security features has made it quite hard to run Valgrind on the tracker-extract-3 process. This is something that at least requires -Dlandlock=disabled -Dseccomp=false at build time, since these syscalls and restrictions will break Valgrind.

This MR makes tracker-miners ship a copy of the valgrind.h header (under a BSD license as it's mostly made to be used c&p) and uses it to detect whether our process(es) run under Valgrind, in order to have this disabling happen at runtime instead of build time.

From the main commit:

Detect running under Valgrind, and turn off Landlock/Seccomp in
order to make the tracker-extract-3 process traceable.

This obviously errs on the side of user friendliness, making it
possible to just run:

$ valgrind --trace-children=yes /usr/libexec/tracker-miner-fs-3

To get reports for both tracker-miner-fs-3 and tracker-extract-3
in a single run, or:

$ valgrind /usr/libexec/tracker-extract-3 -f /path/to/file

To get Valgrind reports of tracker-extract-3 extracting metadata
from an individual file. The current alternative to trace memory usage
in the tracker-extract-3 process is to disable Landlock/Seccomp
functionalities at build time (i.e. requiring a development environment),
this is not great if we have to ask users to run Valgrind for us.

These checks are done prior to dealing with any untrusted data, so
it is implausible that exploits in the filesystem could pre-emptively
alter the environment to turn off these features. And optimistically
the virtualized environment while running under Valgrind should throw
off attempts from exploits to take advantage of memory handling
mishaps. These caveats should not be completely ignored though, if
you have untrusted files and want to profile memory usage of
tracker-miners processes.

An additional measure adopted by tracker-extract-3 when running
under Valgrind is disabling the per-file deadline, since Valgrind
may make things slow enough to challenge it.

And last, this MR includes a fix for some potential leaks in the JPEG extractor on misdetected files.

Related: #337

Merge request reports