Bug 1271872

Summary: break up tracker rpm into -libs and non-libs
Product: [Fedora] Fedora Reporter: Frank Ch. Eigler <fche>
Component: trackerAssignee: Carlos Garnacho <cgarnach>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dakingun, debarshir, dylan.graham, edgar.hoch, fdor6, fedora, gerd, harshula, jbastian, klember, rdieter, rhbz, sergio
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tracker-2.3.1-2.fc32 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-29 13:27:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frank Ch. Eigler 2015-10-14 23:54:12 UTC
A great many users are interested in turning off tracker functionality entirely - systemwide.  Since that does not appear in the works (see bug #747689 e.g.), how about getting the tracker rpm split up, to separate the libraries and the binaries?  That way, nautilus etc. can stay installed (and presumably fail some classes of searches), but at least the tracker binaries could be removed.

Comment 1 Edgar Hoch 2015-10-26 15:51:14 UTC
Perhaps it may help to move /etc/xdg/autostart/tracker-* to a separate package?

Comment 2 Gerd v. Egidy 2015-10-26 16:33:36 UTC
(In reply to Edgar Hoch from comment #1)
> Perhaps it may help to move /etc/xdg/autostart/tracker-* to a separate
> package?

good Idea. 

It would even help to just mark these files with %config(noreplace) in the .spec so that you can disable them and they stay that way even after the tracker rpm is updated.

Comment 3 Jeff Bastian 2015-10-26 19:52:38 UTC
(In reply to Edgar Hoch from comment #1)
> Perhaps it may help to move /etc/xdg/autostart/tracker-* to a separate
> package?


The tracker daemons could still be activated by D-Bus requests, though.

Try chmod'ing those files to 000 and you'll see that tracker doesn't start by default, but it's still available as a D-Bus service:

[jmbastia@localhost ~]$ pgrep -laf tracker
[jmbastia@localhost ~]$
[jmbastia@localhost ~]$ ls -l /etc/xdg/autostart/tracker*
----------. 1 root root 4137 Sep 22 09:28 /etc/xdg/autostart/tracker-extract.desktop
----------. 1 root root 4330 Sep 22 09:28 /etc/xdg/autostart/tracker-miner-apps.desktop
----------. 1 root root 5269 Sep 22 09:28 /etc/xdg/autostart/tracker-miner-fs.desktop
----------. 1 root root 4299 Sep 22 09:28 /etc/xdg/autostart/tracker-miner-rss.desktop
----------. 1 root root 5000 Sep 22 09:28 /etc/xdg/autostart/tracker-miner-user-guides.desktop
----------. 1 root root 4989 Sep 22 09:28 /etc/xdg/autostart/tracker-store.desktop
[jmbastia@localhost ~]$ busctl --user --activatable | grep -i tracker
org.freedesktop.Tracker1                      - -   -   (activatable) -   -
org.freedesktop.Tracker1.Miner.Applications   - -   -   (activatable) -   -
org.freedesktop.Tracker1.Miner.Extract        - -   -   (activatable) -   -
org.freedesktop.Tracker1.Miner.Files          - -   -   (activatable) -   -
org.freedesktop.Tracker1.Miner.RSS            - -   -   (activatable) -   -
org.freedesktop.Tracker1.Miner.Userguides     - -   -   (activatable) -   -
org.freedesktop.Tracker1.Writeback            - -   -   (activatable) -   -


If I monitor the D-Bus and while doing that I open a Nautilus window and click on the Search icon and search for a file, it launches tracker:

[jmbastia@localhost ~]$ busctl --user monitor org.freedesktop.Tracker1
Monitoring bus message stream.
‣ Type=signal  Endian=l  Flags=1  Version=1  Priority=0 Cookie=2
  Sender=org.freedesktop.DBus  Destination=:1.59  Path=/org/freedesktop/DBus  Interface=org.freedesktop.DBus  Member=NameAcquired
  MESSAGE "s" {
          STRING ":1.59";
  };

...

‣ Type=method_call  Endian=l  Flags=0  Version=1  Priority=0 Cookie=7
  Sender=:1.70  Destination=org.freedesktop.DBus  Path=/org/freedesktop/DBus  Interface=org.freedesktop.DBus  Member=StartServiceByName
  UniqueName=:1.70
  MESSAGE "su" {
          STRING "org.gtk.vfs.Daemon";
          UINT32 0;
  };

...
^C

[jmbastia@localhost ~]$ pgrep -laf tracker
10215 /usr/libexec/tracker-store


Thus, it would be best to separate the libraries from the rest of the package as Frank suggested in comment 0.

Comment 4 Igor Gnatenko 2016-07-07 09:17:50 UTC
rishi, what do you think?

Comment 5 Debarshi Ray 2016-07-07 18:19:54 UTC
(In reply to Igor Gnatenko from comment #4)
> rishi, what do you think?

I am not opposed to it, but I am not volunteering to do the work. :)

We need to ensure that tracker is still set up properly on a default Fedora Workstation installation and when updating a Workstation.

Comment 6 Fdor 2016-09-17 11:10:32 UTC
I think a tracker is a risk for privacy, so I don't want anything of it 
installed.

To make it possible, I propose an alternative to the split: Change the rpm
dependency type from "Requires" to "Recommends". Take a look at the "Weak 
dependencies" section (last section) in the following document: 
http://rpm.org/wiki/PackagerDocs/Dependencies

If package A "requires" package B, then you have to install B before A.
But, if package A "recommends" package B, then you are not forced to 
install B before A, you can install B *optionally* to get more features 
from A.

Similarly, if you installed A and B, and A "recommends" B, then you can
uninstall B without uninstalling A. So A will detect that B is not
available now, and will offer less features.

In our case, B is "tracker", and A is every package that currently requires
"tracker". So the tasks to do would be:
1. Change "Requires" to "Recommends" in every A.
2. Add detection of B to every A (to offer more or less features).

Comment 7 Debarshi Ray 2016-09-20 12:32:36 UTC
(In reply to Fdor from comment #6)
> I think a tracker is a risk for privacy, so I don't want anything of it 
> installed.

Privacy? How is that?

Comment 8 Georg Sauthoff 2016-11-21 20:49:15 UTC
@De(In reply to Debarshi Ray from comment #7)
> (In reply to Fdor from comment #6)
> > I think a tracker is a risk for privacy, so I don't want anything of it 
> > installed.
> 
> Privacy? How is that?

one privacy related risk: you copy some sensitive document to your Fedora box and you review it for a short time. In that time the tracker might already have indexed it and the index now contains sensitive words/phrases/snippets even after the document itself is wiped from the system.

There is also this:

https://scarybeastsecurity.blogspot.de/2016/11/0day-poc-risky-design-decisions-in.html

Comment 9 Debarshi Ray 2016-11-22 16:41:43 UTC
(In reply to Georg Sauthoff from comment #8)
> @De(In reply to Debarshi Ray from comment #7)
> one privacy related risk: you copy some sensitive document to your Fedora
> box and you review it for a short time. In that time the tracker might
> already have indexed it and the index now contains sensitive
> words/phrases/snippets even after the document itself is wiped from the
> system.

I see, ok.

There is also:
https://mail.gnome.org/archives/tracker-list/2016-October/msg00003.html

So it might eventually happen.

> https://scarybeastsecurity.blogspot.de/2016/11/0day-poc-risky-design-
> decisions-in.html

The language there, I am afraid, is a bit dramatic. I commented on that article, but unfortunately, Blogspot identified me as "Unknown" even though I chose to identify with the my Google account. I will copy/paste:

"Bugs like this are the primary reason why Tracker extracts metadata from files in a separate tracker-extract process. That process runs entirely in the background, and chances are very high that a crash won't affect a user-facing application. For example, Chrome didn't crash as a result of the tracker-extract crash.

For a user-facing application to crash, it has to run gstreamer's vmncdec in-process. That is why totem crashes if you try to run this file.

Forget Tracker. The way things stand today, someone can potentially exploit Firefox (and lot of other software) to steal your private keys, or spy on your using the laptop's camera. I believe the long term answer involves:

(a) Sandboxed Flatpak (http://flatpak.org/) applications. So that any random application on the computer can not perform any potentially suspicious activity behind the user's back.

(b) Portals that act as gatekeepers to such resources (like network, camera, files). I can imagine a 'import from web browser' portal that will explicitly let you select a file from the web that you want to expose to the rest of the desktop."

Comment 10 Debarshi Ray 2016-11-22 16:44:28 UTC
(In reply to Georg Sauthoff from comment #8)
> @De(In reply to Debarshi Ray from comment #7)
> > (In reply to Fdor from comment #6)
> > > I think a tracker is a risk for privacy, so I don't want anything of it 
> > > installed.
> > 
> > Privacy? How is that?
> 
> one privacy related risk: you copy some sensitive document to your Fedora
> box and you review it for a short time. In that time the tracker might
> already have indexed it and the index now contains sensitive
> words/phrases/snippets even after the document itself is wiped from the
> system.

Also, things like these are probably better covered through an option in Settings -> Privacy, instead of expecting non-technical users to know how to tinker with the operating system.

Comment 11 Carlos Garnacho 2016-11-22 17:48:05 UTC
(In reply to Georg Sauthoff from comment #8)
> @De(In reply to Debarshi Ray from comment #7)
> > (In reply to Fdor from comment #6)
> > > I think a tracker is a risk for privacy, so I don't want anything of it 
> > > installed.
> > 
> > Privacy? How is that?
> 
> one privacy related risk: you copy some sensitive document to your Fedora
> box and you review it for a short time. In that time the tracker might
> already have indexed it and the index now contains sensitive
> words/phrases/snippets even after the document itself is wiped from the
> system.

The information is stored in files only readable by your user, if storing a textual representation with such permissions is a privacy risk, then what prevents the attacker from accessing the file directly?

Also, it's not true that the extracted information is preserved after the file is deleted, all full-text search tokenization data is deleted as soon as tracker-miner-fs notices the file is deleted.

Comment 12 Jeremy L. Gaddis 2017-09-13 06:24:32 UTC
(In reply to Carlos Garnacho from comment #11)
> The information is stored in files only readable by your user, if storing a
> textual representation with such permissions is a privacy risk, then what
> prevents the attacker from accessing the file directly?
> 
> Also, it's not true that the extracted information is preserved after the
> file is deleted, all full-text search tokenization data is deleted as soon
> as tracker-miner-fs notices the file is deleted.

For one example of how a poor choice of defaults (with regard to tracker) affected security, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754907 (discovered via https://bugzilla.redhat.com/show_bug.cgi?id=747689#c54).

In this particular case, file contents were ending up being logged via syslog. It's not hard to imagine a scenario in which /home is encrypted but /var/log is not or (worse!) the file's contents end up being sent over the network in plain-text due to remote logging.

Yes, this particular issue has been fixed but other, similar issues cannot be ruled out.

Comment 13 Sergio Basto 2017-09-17 14:52:25 UTC
why tracker started to run on Fedora KDE 26 installation ?

Comment 14 Kalev Lember 2019-07-19 10:52:15 UTC
I went ahead and split off libtracker-sparql into a separate subpackage. This doesn't fully solve this ticket, but gets a bit closer. Testing welcome: https://bodhi.fedoraproject.org/updates/FEDORA-2019-47ff8c9273

Comment 15 Edgar Hoch 2019-08-23 19:51:14 UTC
(In reply to Kalev Lember from comment #14)
> I went ahead and split off libtracker-sparql into a separate subpackage.
> This doesn't fully solve this ticket, but gets a bit closer. Testing
> welcome: https://bodhi.fedoraproject.org/updates/FEDORA-2019-47ff8c9273

I have tried to remove installed packages tracker and tracker-miners from a Fedora 30 system. Both would also remove important desktop packages like nautilus, so this removing is still not an option.

Removing the package is also not my preferred way to deal with the problem. I still want to provide the software to our users, and they should be able to activate it if they want to use it. But many ouf our users (amoung others students) don't use it, they even don't know that they can use it. But the software still runs in the background, consumes much disk space in the home directory of every user, and most of them don't want to find files on the local system, because it only contains the Fedora system, but all user files are shared from nfs servers. So I would prefer the ability to set a system-wide flag or similar (e.g. just call systemctl with some options to disable the service?) so that it is not autostarted on user login by default, but users can enable it for their account themself. 


I have recognized that the autostart files are declared as noreplace config files in the rpm spec file. This is a very helpful improvement, thanks! It meens that my changes that I make with post-installation scripts (X-GNOME-Autostart-enabled=false) will stay intact after an package upgrade. Modifying a preinstalled autostart desktop file is not an optimal solution, but for the moment it solves the problem.

%config(noreplace) %{_sysconfdir}/xdg/autostart/tracker*.desktop

Comment 16 Kalev Lember 2019-08-26 12:20:18 UTC
(In reply to Edgar Hoch from comment #15)
> (In reply to Kalev Lember from comment #14)
> > I went ahead and split off libtracker-sparql into a separate subpackage.
> > This doesn't fully solve this ticket, but gets a bit closer. Testing
> > welcome: https://bodhi.fedoraproject.org/updates/FEDORA-2019-47ff8c9273
> 
> I have tried to remove installed packages tracker and tracker-miners from a
> Fedora 30 system. Both would also remove important desktop packages like
> nautilus, so this removing is still not an option.

Yep, this only works with packages like bijiben that only use libtracker-sparql and don't have dependencies on the rest of tracker. Other core desktop apps such as nautilus need more tracker functionality, so the libtracker-sparql split doesn't help with them.


> Removing the package is also not my preferred way to deal with the problem.
> I still want to provide the software to our users, and they should be able
> to activate it if they want to use it. But many ouf our users (amoung others
> students) don't use it, they even don't know that they can use it. But the
> software still runs in the background, consumes much disk space in the home
> directory of every user, and most of them don't want to find files on the
> local system, because it only contains the Fedora system, but all user files
> are shared from nfs servers. So I would prefer the ability to set a
> system-wide flag or similar (e.g. just call systemctl with some options to
> disable the service?) so that it is not autostarted on user login by
> default, but users can enable it for their account themself. 

Maybe you could open a ticket at http://gitlab.gnome.org/GNOME/tracker and discuss the idea there? I am not familiar enough with tracker internals to comment if it would make sense or not.


> I have recognized that the autostart files are declared as noreplace config
> files in the rpm spec file. This is a very helpful improvement, thanks! It
> meens that my changes that I make with post-installation scripts
> (X-GNOME-Autostart-enabled=false) will stay intact after an package upgrade.
> Modifying a preinstalled autostart desktop file is not an optimal solution,
> but for the moment it solves the problem.
> 
> %config(noreplace) %{_sysconfdir}/xdg/autostart/tracker*.desktop

Great! Glad it helped.

Comment 17 Kalev Lember 2019-11-29 13:27:39 UTC
I went ahead and split out libtracker-control and libtracker-miner out to separate subpackages as well in https://src.fedoraproject.org/rpms/tracker/c/fe0fd7313b98076f21160900376ebea5efb096f8?branch=master