Bug 1271872 - break up tracker rpm into -libs and non-libs
break up tracker rpm into -libs and non-libs
Status: NEW
Product: Fedora
Classification: Fedora
Component: tracker (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Igor Gnatenko
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-14 19:54 EDT by Frank Ch. Eigler
Modified: 2017-09-17 10:52 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Ch. Eigler 2015-10-14 19:54:12 EDT
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 11:51:14 EDT
Perhaps it may help to move /etc/xdg/autostart/tracker-* to a separate package?
Comment 2 Gerd v. Egidy 2015-10-26 12:33:36 EDT
(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 15:52:38 EDT
(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 05:17:50 EDT
rishi, what do you think?
Comment 5 Debarshi Ray 2016-07-07 14:19:54 EDT
(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 07:10:32 EDT
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 08:32:36 EDT
(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 15:49:15 EST
@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 11:41:43 EST
(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 11:44:28 EST
(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 12:48:05 EST
(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 02:24:32 EDT
(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 Monteiro Basto 2017-09-17 10:52:25 EDT
why tracker started to run on Fedora KDE 26 installation ?

Note You need to log in before you can comment on or make changes to this bug.