Bug#887860: tracker-extract: repeated SIGSYS in execve()

[Simon McVittie]

On Sat, 20 Jan 2018 at 15:08:18 -0800, Mike Kupfer wrote:
> Every few days I find a core file in $HOME.  file(1) tells me they're
> coming from tracker-extract.  I've taken a quick look at a couple with
> gdb, and (IIRC), gdb has said each time that tracker-extract died with
> SIGSYS in execve().

tracker-extract runs under seccomp sandboxing that kills it with SIGSYS
when it tries to do a system call that isn't on a whitelist, to make sure
an attacker wouldn't be able to use a vulnerability in its file parsing
to execute arbitrary code. Executing a different binary (execve())
is not on the whitelist.

> #2  0x00007fde9dc5c31e in g_execute (search_path_from_envp=0, search_path=0, envp=0x0, argv=0x7fde6bb198b0, file=0x7fde641bb000 "/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner") at ././glib/gspawn.c:1680

This is a GStreamer library used by tracker-extract refreshing its
list of available GStreamer plugins. tracker-extract should configure
GStreamer to not do this: either it currently doesn't, or it tries to
but has been unsuccessful. Before applying seccomp filters or making
use of GStreamer, tracker-extract should set the environment variables
GST_REGISTRY_UPDATE and GST_REGISTRY_FORK to "no" to prevent this.

I'm not sure under what circumstances GStreamer runs gst-plugin-scanner:
it must be something slightly unusual about your system, perhaps a
locally-installed GStreamer plugin with a timestamp newer than the
registry of available plugins, otherwise other people would see this
bug all the time.

    smcv