Hello, tracker people. I’m here to discuss a problem that I have encountered which made my system unresponsive, requiring a hard reset to get out of, and which occurred every time I subsequently logged into my machine until I finally diagnosed it (in two minute chunks, with a reboot in between each opportunity for debugging).
Essentially, at some point shortly before the issue occurred, I dropped my keyboard onto my chest, or my cat did anyway (I am disabled and use my machine from bed with a rolling table that’s above me). When the keyboard fell, it hit the windows-logo button (I think that’s referred to as “Super”? but I’m not sure so sorry for the microsoft reference) and also the ~/` key, resulting in the Ubuntu launcher overlay popping up and then input to the search function that looked like this:
```````````````````````````````````````````````````````````````````
In other words, just a long string of back-tics probably hundreds of characters long by the time I was done petting the cat and picked the keyboard back up. I thought nothing of it and closed the overlay.
This results in some tracker process consuming the entirety of a 6-core cpu. The cpu usage doesn’t begin until the first time something causes the tracker background processes to begin, and then slowly ramps up, so at the beginning it’s difficult to notice, but after a minute or two the entire desktop is unusable, and shortly after that it’s impossible to even type characters in the Ctrl-Alt-F2 terminal.
Issuing a “tracker reset --hard” command and answering yes at the “are you sure?” prompt resolves the issue.
I would raise an issue via git, but I’m not completely certain whether this would be considered a bug by most people, and discourse looks like a nicer place to hold that discussion if needed than in git bug report.
So, I just want to bullet point a few thoughts, and then let people who know tracker better than me (I only discovered it exists via the issue above) figure out what to do about it, whether to treat it as a bug or an enhancement request, what relative priority to assign, etc.
-
Is it possible to effectively limit the total cpu usage by the various tracker processes, in case a similar bug occurs even after this one gets fixed?
-
Could this be a security issue? For example, does tracker index any sources that are world-writable by default, or that include locations that may have been made world-writable by the user? Or read from the network? Etc.
-
Even if not, could this be considered a security issue from the perspective of remote users / server processes on a machine that also has a console user, who is essentially performing a local denial of service attack against the rest of the machine?
-
When fixing this bug, I assume mostly by ensuring that inputs are checked for sanity, what other sanity checks should be performed? It’ll be easy to add any checks needed at the same time, and I’m sure that if this input causes issues, there are going to be other classes of input that also cause issues.
-
When checking input specifically in the application search menu, should the input be checked as each character is typed, or when the user is done typing?
-
Is any other fix possible, in a “belt and suspenders” or “don’t put all your eggs in one basket” spirit, beyond input checking?
I would appreciate feedback on the correctness of my approach with this message, as I am new to discourse.gnome.org and may have erred in some way. Anything correctable will be cheerfully corrected.
Likewise, it seems the transition from the tracker mailing list is in progress, so I would appreciate any response by a tracker developer to let me know that this message has reached its target audience.
. Still requires write access to the indexed locations as another user.