the debuginfod-client creates 000-permissions files as a way to mark "negative caching". Unfortunately, that causes permissions problems for backup software, disk usage checkers, etc. that rely on being able to access the user's own files. Given that the usage of those 000-permission files is not even atomic (see commit 7d64173fb11c66284a408e52d41d15b7755d65d2), is there any reason not to use the contents of the file, or the name of the file, or some other attribute like the xattrs as a way to carry that "negative cache" information? My backup software's log is hundreds of lines of: Warning: /home/hadess/.var/app/org.gnome.Totem.Devel/cache/debuginfod_client/d9ebf6de9e98f66a21daca59c8f601a9daa03c5b/debuginfo: open: [Errno 13] Permission denied: '/home/hadess/.var/app/org.gnome.Totem.Devel/cache/debuginfod_client/d9ebf6de9e98f66a21daca59c8f601a9daa03c5b/debuginfo'
For what it's worth, these caches are all disposable, so you could exclude the whole directory structure from backups or just delete it. I'm not keen on a file-attribute solution, because it's less portable and it'd still require SOME file to exist. A 0-length file is not unambiguous (consider empty source files). A differently named file is a possibility. (Pretty sure atomicity is an orthogonal consideration - TOCTOU is a possibility with all the options.)
Theoretically you can have a totally empty source files, but they are pretty useless and they won't even leave any debug (DWARF) data (except for an empty line table and compiler options string), so since there is no DWARF reference to the source file it won't even be requested by any debuginfod consumer. executables and debug files are ELF so are never zero size. So I think it might make some sense to investigate whether we can use the fact that a file is zero size as negative cache indicator. It would also get rid of the "root is special" case. At least I cannot imagine we really want to ever return a zero sized file. But I might not have big enough imagination. There is always some theoretically possibility that there is a legitimate request for a zero sized file in the future. But do we really need to worry about that? Does it prevent some future extensions?
I can't come up with a convincing example why 0-length files would be bad, just general unease at the ambiguity. I don't mind switching to it for now; at worst, later on we may have to revise and then arrange to clean out caches once.
Aaron already wrote up a patch to use zero sized files as negative cache instead of zero permission files: https://sourceware.org/pipermail/elfutils-devel/2022q2/004861.html The only question is how this works on upgrade with an old cache. But it might just work out because the old negative cache files were also zero sized and the unlink should just work despite any changes in permissions. If someone could try it out and/or give it a formal review that would be great.
A fix has been pushed as: commit 8b568fdea8e1baea3d68cc38dec587e4c9219276 Author: Aaron Merey <amerey@redhat.com> Date: Fri Apr 8 19:37:11 2022 -0400 PR29022: 000-permissions files cause problems for backups 000-permission files currently used for negative caching can cause permission problems for some backup software and disk usage checkers. Fix this by using empty files for negative caching instead. Also use each empty file's mtime to determine the time since last download attempt instead of the cache_miss_s file's mtime. https://sourceware.org/bugzilla/show_bug.cgi?id=29022 Tested-by: Milian Wolff <mail@milianw.de> Signed-off-by: Aaron Merey <amerey@redhat.com>