Bugzilla – Bug 1213336
AUDIT-1: gnome-settings-daemon: possibly unsafe recursive deletion logic for /tmp, /var/tmp
Last modified: 2023-08-23 10:36:32 UTC
+++ This bug was initially created as a clone of Bug #1204311 This is about gsd-housekeeping and unit gsd-disk-space.c. It deletes outdated files in the user's home directory (e.g. cache directories, thumbnails etc.). This also has some potentially dangerous /tmp and /var/tmp cleanup mechanisms in `gsd_ldsm_purge_temp_files()`, but it isn't used if systemd-tmpfiles tmp.conf is present. But this file doesn't seem to be present on TW? The `delete_subdir_check_symlink()` seems racy.
So this should be unproblematic for the following reasons: - the temp file cleanup logic is disabled by default, but can be enabled explicitly (in a low level way) by calling: gsettings set org.gnome.desktop.privacy remove-old-temp-files true - the logic only funs once per hour and removes files older than 30 days (by default). - the logic is not triggered if systemd is running, which is determined by checking the existence of /run/systemd/system. This is the case in our distributions. So the logic will never be reached. Also a comment from the source code: ``` /* Never clean temporary files on a sane (i.e. systemd managed) * system. In that case systemd already ships * /usr/lib/tmpfiles.d/tmp.conf * which does the trick in a much safer way. * Ideally we can just drop this feature, I am not sure why it was * added in the first place though, it does not really seem like a * privacy feature (also, it was late in the release cycle). * https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence * * This does the same as sd_booted without needing libsystemd. */ if (g_file_test ("/run/systemd/system/", G_FILE_TEST_IS_DIR)) return; ``` So somebody upstream was aware of the problematic logic. If the logic runs it likely has issues and might allow to remove older files from the user's home directory. We shouldn't waste time on practically dead code though. Closing this bug as fixed.