GNOME Bugzilla – Bug 778182
tracker-extract constantly segfaults in flistxattr
Last modified: 2017-04-19 18:30:11 UTC
tracker-extract generate several core dumps per minute with this stack trace: PID: 1558 (tracker-extract) UID: 1000 (cedric) GID: 100 (users) Signal: 31 (SYS) Timestamp: Sat 2017-02-04 21:46:00 CET (4min 1s ago) Command Line: /usr/lib/tracker/tracker-extract Executable: /usr/lib/tracker/tracker-extract Control Group: / Slice: -.slice Storage: /var/lib/systemd/coredump/core.tracker- Message: Process 1558 (tracker-extract) of user 1000 dumped core. Stack trace of thread 1577: #0 0x00007fa783641f47 flistxattr (libc.so.6) #1 0x00007fa7847b41dd n/a (libgio-2.0.so.0) #2 0x00007fa7847b5e20 n/a (libgio-2.0.so.0) #3 0x00007fa78472ce1d g_file_input_stream_query_info (libgio-2.0.so.0) #4 0x00007fa784721df6 g_file_copy (libgio-2.0.so.0) #5 0x00007fa7842c866c media_art_process_file (libmediaart-2.0.so.0) #6 0x00007fa76770fb99 tracker_extract_get_metadata (libextract-mp3.so) #7 0x000000000040b046 n/a (tracker-extract) #8 0x000000000040b113 n/a (tracker-extract) #9 0x000000000040b170 n/a (tracker-extract) #10 0x00007fa783b880d5 n/a (libglib-2.0.so.0) #11 0x00007fa783900454 start_thread (libpthread.so.0) #12 0x00007fa7836437df __clone (libc.so.6) Stack trace of thread 1560: #0 0x00007fa78363a48d poll (libc.so.6) #1 0x00007fa783b60786 n/a (libglib-2.0.so.0) #2 0x00007fa783b6089c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fa783b608e1 n/a (libglib-2.0.so.0) #4 0x00007fa783b880d5 n/a (libglib-2.0.so.0) #5 0x00007fa783900454 start_thread (libpthread.so.0) #6 0x00007fa7836437df __clone (libc.so.6) I have the same issue if I restart the machine: Sat 2017-02-04 21:45:54 CET 899 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:45:55 CET 1313 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:45:56 CET 1334 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:45:59 CET 1362 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:45:59 CET 1507 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:46:00 CET 1558 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:48:06 CET 1854 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:48:06 CET 1996 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:48:07 CET 2029 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:48:10 CET 2059 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:48:10 CET 2199 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:50:13 CET 2290 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:50:16 CET 2318 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:50:16 CET 2461 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:50:17 CET 2494 1000 100 31 present /usr/lib/tracker/tracker-extract Sat 2017-02-04 21:50:20 CET 2523 1000 100 31 present /usr/lib/tracker/tracker-extract I am using version 1.10.4-2 on ArchLinux (Up to date)
This is sadly a shortcoming in sandboxing support that I can't do much in stable series to further improve. I recommended all downstream packagers to use --disable-libmediaart for the time being, and I see archlinux followed the recommendation: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/tracker#n41 I'm closing as NOTGNOME on the lack of a better status.
Created attachment 347665 [details] [review] Patch whitelisting flistxattr This bug also affects the Fedora 25 tracker package. See https://bugzilla.redhat.com/show_bug.cgi?id=1419183. tracker-extract is killed by SIGSYS when scanning ogg vorbis files. This is due to missing seccomp permissions for flistxattr(2), which is invoked by gio via libmediaart. Since neither gio nor libmediaart support seccomp, this system call needs to be allowed in libtracker.
See https://git.gnome.org/browse/tracker/log/src/libtracker-common/tracker-seccomp.c where many similar syscalls have been allowed.
Thanks very much for the patch, but that is not (only) it. Unfortunately the whole albumart handling is a path to disaster, flistxattr is used in the first stages of g_file_copy() in order to copy the extended attributes after copying the file. Actually all albumart handling involve some sort of open(O_RDWR) or symlink() syscalls, while both are forbidden inside the sandbox. Albumart handling, seen more generically, is the ability to write random binary buffers to an specific folder. I don't think this can be done in an entirely secure manner, these random binary buffers come from the same code we're trying to sandbox, and could be used maliciously. I rather stay on the safe side for Tracker and defer this to clients, which can properly run on flatpak if this turns a real concern. I eg. filed bug #779584 to gnome-music so it can do albumart extraction by itself. Whitelisting flistxattr sounds entirely harmless indeed, but I still think --disable-libmediaart is the only fix I can advise, it is even turned off for good in 1.11/1.12/master.
*** Bug 779875 has been marked as a duplicate of this bug. ***