GNOME Bugzilla – Bug 775301
"Purge Temporary Files" severely broken
Last modified: 2019-03-20 11:38:42 UTC
The cleanup functionality in /var/tmp seems to happily step into networked FSs that happen to be there. In my case, I've had an sshfs mount of my home directory on a different machine, and the next morning I woke up to a dysfunctional machine since large parts of my home directory just vanished. (I have intentionally set the severity field to "critical", since this can be a potential disaster to more people.)
Please provide more information about your setup and why you'd mount a /home directory in /var/tmp.
1. I have the version that is currently shipping with Fedora 25, without any additional customizations or tweaks. RPM says: Name : gnome-settings-daemon Version : 3.22.1 Release : 1.fc25 Architecture: x86_64 Install Date: Tue 15 Nov 2016 04:34:09 PM EST [...] Source RPM : gnome-settings-daemon-3.22.1-1.fc25.src.rpm Build Date : Wed 12 Oct 2016 03:00:31 PM EDT [...] 2. I had a temporary job to do with two machines. A temporary sshfs mount is very convenient for that kind of thing. /var/tmp (or /tmp) sound like a perfectly fine place for a temporary mount. 3. Actually, scratch #2: the reason I did it is irrelevant; the disaster that followed is a good reason. To elaborate on this: Implicit in the "why you'd [...]" question is a claim that "it might be reasonable to enter it while cleaning up old tmp files" -- and I claim that this is completely and utterly unreasonable. Considering the question of whether it is a good thing to do or not: a. `systemd-tmpfiles --cleanup` does not go into network mounts. Other & older tmp cleaners (eg, tmpwatch, tmpreaper) would also never descend into a different filesystem. b. The question of whether files should be cleaned up or not is a question about *local* disk mount policy only, and should never apply to mounts that are *inside* the directory. For example, had I mounted /var/tmp *itself* as an sshfs, I wouldn't be surprised if it'd be subject to the policies that usually govern /var/tmp; but that was not the case. Given both points, I think that it's the gnome-settings-daemon's developers responsibility to demonstrate a valid reason to *do* descend into foreign mounts: both logically (to counter (b)), and concretely (to counter (a)): find the reason all of these tmp cleaners avoid mounts, and explicitly decide why that reason is no longer valid. 4. As a side-note, these older tmp cleaners also all avoid following symlinks. If anyone would have done the common sense thing of looking up behaviors of existing cleaners, gnome-settings-daemon would have not followed symlinks as well, avoiding a similarly catastrophic bug that was filed about two years ago (730223 and 737079). 5. To clarify, in my case "disaster" refers to the fact that I spent pretty much all of a very long weekend recovering files. (Actually, recovering was easy, reconstructing proper selinux contexts took days.) Note that similar language was used in the earlier symlink bug. The bottom line: PEOPLE LOSE DATA, which should not happen unintentionally. It baffles me that a reaction to such a bug report is "why did you do that?". 6. Yet another side-note related to all of this. One thing that I noted that gnome-settings-daemon does differently than previous tmp cleaners is that it uses mtime/atime to determine when files should be deleted, but it doesn't use ctime. AFAICT, this can lead to similarly amusing situations in which I unpack some old tgz archive in /var/tmp to look at its contents, and immediately have files disappear from it. This should be fixed too.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/312.