GNOME Bugzilla – Bug 776117
False positives in sandboxing restrictions
Last modified: 2021-05-26 22:24:55 UTC
Created attachment 341984 [details] Core Dump System disk is a USB. When I copy from another USB drive to the USB system disk core dumps repeatedly.
Created attachment 341985 [details] Core Dump
Created attachment 341987 [details] Core Dump
Created attachment 341990 [details] System startup core dump. This core dump happens at system start.
Thanks for the bug report. It would be great if you could obtain the backtraces through: $ gdb /usr/libexec/tracker-extract ./core.tracker-extract... (gdb) t a a bt And paste those here. I have neither your same version, dependencies nor architecture, so can't get much info of the coredump files you attached.
This system disk is only 16gb with less than 4gb free. It this be a problem? Can I set preferences to consider this?
Created attachment 341997 [details] GDB debug info Here is one if u need more say so.
Created attachment 341998 [details] Tracker GDB Startup Known dump from startup.
Thanks, that was useful. Turns out your 32bit arch triggers false positives in the brand new extraction sandbox, so the process terminates with SIGSYS due to "invalid" syscalls being performed. I only have 64bit installs around, so didn't see this. I'm attaching/pushing a patch that whitelists syscalls that might be useful there, however the bug will remain open in the hope that you can confirm you no longer get crashes with the patch, if not I'll eventually setup a 32bit VM and try there myself.
Created attachment 342010 [details] [review] libtracker-common: Whitelist *64() stat/getdents syscalls Those variants may end up called depending on architecture and other factors, there's no reason for those to be blacklisted.
Comment on attachment 342010 [details] [review] libtracker-common: Whitelist *64() stat/getdents syscalls Attachment 342010 [details] pushed as 14f77ae - libtracker-common: Whitelist *64() stat/getdents syscalls
If you want me to apply a patch you're gonna have to give me some guidance since I'm a noob when it comes to patching.
Created attachment 342036 [details] [review] libtracker-common: Whitelist more syscalls used on non-x86_64 arches These ones were spotted after compiling Tracker on i686.
Will I see this in the repository soon?
....also launching the gnome-photos app causes repetitive core dumps.
All fixes are now in git. This IMO warrants new Tracker releases which I'll do tomorrow. I guess/hope your distro of choice should pick up those soon. As for the gnome-photos issue, that sounds entirely unrelated. This extractor sandbox is specific to the tracker-extract daemon. I suggest you file a separate bug addressed to gnome-photos. Attachment 342036 [details] pushed as fff1ba0 - libtracker-common: Whitelist more syscalls used on non-x86_64 arches
It may be related since gnome-photos seems to be indexing photos with Tracker? I'll wait to see if the update takes care of it before filing a bug report.
Thanks for your prompt response to this issue, I'll test as soon as I get the update & post my results on this open bug report.
(In reply to Phil Reilly from comment #14) > ....also launching the gnome-photos app causes repetitive core dumps. What is crashing? Is gnome-photos itself crashing? Or is it causing a tracker process to crash?
FWIW 1.10.3 and 1.8.2 are already out.
(In reply to Debarshi Ray from comment #18) > (In reply to Phil Reilly from comment #14) > > ....also launching the gnome-photos app causes repetitive core dumps. > > What is crashing? Is gnome-photos itself crashing? Or is it causing a > tracker process to crash? gnome-photos not dumping. Multiple triggers causing tracker core dumps probably not limited to: 1. system startup/login 2. usb file transfer to system 3. launching gnome-photos as it indexes user's photos & I'm guessing there are more. I'm waiting to update before openening more bug reports.
Created attachment 342089 [details] Core dump after patched 1 Dump after new versions installed. Dumps keep coming & had to uninstall tracker.
Created attachment 342090 [details] Another dump after new versions installed. Dump after new versions installed. Dumps keep coming & had to uninstall tracker.
Created attachment 342117 [details] [review] libtracker-common: Whitelist gettimeofday() syscall
Comment on attachment 342117 [details] [review] libtracker-common: Whitelist gettimeofday() syscall Attachment 342117 [details] pushed as 88cfdc5 - libtracker-common: Whitelist gettimeofday() syscall
Hi Phil, I think at this point it might be better if you tried compiling Tracker yourself, as it's going to be very spotty otherwise... You might (and seem to) hit some files that use plugins I don't run into with my testing data set, as soon as one of those plugins does a syscall that is not observed in the sandbox, this would keep happening. I would recommend jhbuild for the task, it's the helper script many gnome devs use to compile (parts of) the gnome platform, it will clone/update git repos to a directory in your home folder, compile orderly and install to another directory in your home folder. You can then run manually run things from that directory, and eventually delete it altogether without affecting your base install. There's instructions to set up jhbuild at https://wiki.gnome.org/Newcomers/BuildGnome , some more specific steps after you got it working are: 1) Make sure you install -devel/-dev packages for some tracker dependencies, besides the basic dependencies listed in that wiki page, those would include: libjpeg, giflib, gstreamer1, poppler-glib, totem-pl-parser, icu, upower, sqlite. If you get those right, you might be able to build only tracker, doing: $ jhbuild buildone tracker Otherwise you might just compile most of these deps from git too doing: $ jhbuild build tracker That should greatly reduce the number of -devel packages you need installed, but would take some more time. 2) Additionally, install strace, it will give us in a clearer way the same info I've been deducing from your backtraces. 3) Once tracker is built, it will be easier to reinstall tracker in your system and only run the tracker-extract executable from inside the jhbuild environment, you'd do in one terminal tab: $ tracker daemon -s $ killall -15 tracker-extract ; strace -f ~/jhbuild/install/libexec/tracker-extract 2>&1 | grep SIGSYS That will restart daemons, and replace the tracker-extract process with the one you just compiled, running through strace will produce a line similar to this whenever the process terminates due to this reason: [pid 5739] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f507b685d37, si_syscall=__NR_gettimeofday, si_arch=AUDIT_ARCH_X86_64} --- 4) Paste those lines here, I'll try to fix ASAP 5) you again rebuild tracker with: $ jhbuild buildone tracker 6) We repeat steps 3,4 and 5 till this is all finished. 7) In order to make it dead sure that everything was fixed, you can reset tracker file info and reindex doing: $ tracker reset -f /path/to/configured/folder This will make tracker reindex the given directory as per the configuration, as if it first found it. I'm sorry for this burden, but it will allow fixing any remaining issue in a much tighter loop. I fixed this last one you reported, but there could be no more issues just like there could be 10 more, and I'd rather not involve further releases and extra work on distros to fix this for good.
I'm doing this on Apricity so if someone puts this build into the AUR repository I can build it from there otherwise I can't commit.
I am using fedora 25 so have no easy way to do that, you can perhaps download the arch PKGBUILD file for Tracker at https://git.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/tracker And modify the source=... line to: source=("git+https://git.gnome.org/browse/tracker#branch=tracker-1.10") After that running makepkg should give you the packages to replace your system's, compiled from the most recent tracker-1.10 branch changes.
We also got this downstream bug report with 1.10.3 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848842
Created attachment 342335 [details] [review] libtracker-common: Handle mlock*/munlock* syscalls Disallow pinning memory on RAM, but make it softly fail with EPERM.
Created attachment 342337 [details] [review] libtracker-common: Allow querying process stats/limits Modifying those is not allowed though.
Thanks for the info Michael :), I'll make yet another set of releases during the weekend with the accumulated patches. Hopefully we get closer to forgetting this ever happened...
Attachment 342335 [details] pushed as c9acfe0 - libtracker-common: Handle mlock*/munlock* syscalls Attachment 342337 [details] pushed as 47b4958 - libtracker-common: Allow querying process stats/limits
Carlos, did you see https://bugzilla.gnome.org/776271
Oops, I didn't, thanks for pointing it out Jeremy :). I however saw a ubuntu bug report linked at the debian bug in comment #28, which seems to be the same issue you forwarded there, the patch allowing getrusage() in comment #30 here should fix it. I'll mark as dup of this one, and during the weekend I'll cherry-pick the relevant patches in all branches and make another set of releases.
*** Bug 776271 has been marked as a duplicate of this bug. ***
Hi Carlos, how is the new release coming along? I see that the tracker-1.10 does not have all of the fixes from the master branch yet. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848842#36 saw a more detailed reply by Simon. You might also be interested in his idea at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851148#41 (can file a separate bug report for that)
There are two more syscalls I needed to whitelist for Tracker >=1.11.2 to work on my system (Fedora 26). The first one is "getpid". Here is a backtrace of it being used by the gstreamer module: Thread 23 "single" received signal SIGSYS, Bad system call.
+ Trace 237070
Thread 140736275040000 (LWP 27458)
I've just released 1.10.4 and 1.8.3, together with yesterday's 1.11.3. These all contain all the latest whitelisting fixes... (In reply to Sebastian Keller from comment #37) > There are two more syscalls I needed to whitelist for Tracker >=1.11.2 to > work on my system (Fedora 26). > > The first one is "getpid". Here is a backtrace of it being used by the > gstreamer module: ...except this one, which is included in 1.10/1.8, but didn't make it to 1.11.3. Would be great if you could downgrade to 1.10.4 when it's packaged and test further with it :).
I just noticed bugzilla ate the rest of my comment after the trace. I already added getpid to the whitelist and then Tracker got stuck on wait4 when trying to call waitpid. This happened when indexing a gzipped PS file. After adding "wait4" to the whitelist, it was able to index all files again. Thread 26 "single" received signal SIGSYS, Bad system call.
+ Trace 237071
Thread 140735944771328 (LWP 22560)
Ouch :), I just pushed the wait4 fix to all 3 branches, but that unfortunately means no release is up-to-date enough for you... I'll eventually roll another unstable tarball. On the plus side, you already have the files indexed, and shouldn't be reindexed unless they change, you should be able to run 1.11.3 without a hitch now (until some new file possibly triggers these or other false positives, that is)
in openSUSE Leap 42.3 / SLE-12 SP3 we see several issues with tracker 1.8.3 https://bugzilla.opensuse.org/show_bug.cgi?id=1017652 patches that fixed this are here: https://build.opensuse.org/request/show/579801 some seem to be resolved by applying some tracker 1.12 branch changes to the tracker 1.8 branch: tracker-whitelist-dup2-dup3.patch also: - gstreamer v4l2 plugin that triggers creation of a NETLINK socket in systemd-udev - gst-plugin-scanner fork : tracker-gst-v4l2-and-scanner-workaround.patch I'm attaching both patches for review
Created attachment 368897 [details] [review] patch for gstreamer v4l2 plugin and plugin scanner
Created attachment 368898 [details] [review] tracker 1.12 -> 1.8 calls alignment
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.