On 4/26/19 12:53 AM, Michał Górny wrote: > > No. tmpfiles is also used for programs started directly by user, such > as eix. >
This configuration is buggy to begin with: if I run eix-update as my user, then the permissions on the files it creates under /var/cache/eix are wrong (mjo:mjo, mode 664). If I run eix as root and it drops privileges, then the permissions on the files it creates are correct (portage:portage, mode 664). But when I run eix as root, eix can create /var/cache/eix itself! It doesn't need the tmpfiles entry in the scenario that works. Maybe a setgid bit could make sense of things, but the simplest solution is probably best: a per-user cache. Regardless of the particulars of eix, I'm a lot skeptical of treating directories under /var/cache as temporary in the first place. It leads to problems just like this one, where a non-root process can't be sure that its cache directory will exist and have the correct permissions. In this case we've solved the problem by requiring either OpenRC or systemd, but that's not a good answer. We would be much better off if the ebuild could create that directory with the correct permissions once, and know that it will persist. The FHS is ambiguous here: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html It calls out files specifically, Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories. The fact that we can't track the directory /var/cache/eix without a file at /var/cache/eix/.keep is something else to worry about, but that's a problem we've caused ourselves and one worth ignoring if it saves us enough trouble.
