Bug 1271872
Summary: | break up tracker rpm into -libs and non-libs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Frank Ch. Eigler <fche> |
Component: | tracker | Assignee: | Carlos Garnacho <cgarnach> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | 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
Perhaps it may help to move /etc/xdg/autostart/tracker-* to a separate package? (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. (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. rishi, what do you think? (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. 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). (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? @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 (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." (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. (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. (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. why tracker started to run on Fedora KDE 26 installation ? 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 (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 (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. 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 |