Hi Michael,
Michael Orlitzky wrote on Mon, Aug 19, 2019 at 07:24:43PM -0400:
> Section 5.5 of the FHS says (quoted in its entirety),
>> /var/cache is intended for cached data from applications. Such data
>> is locally generated as a result of time-consuming I/O or
>> calculation. The application must be able to regenerate or restore
>> the data. Unlike /var/spool, the cached files can be deleted without
>> data loss. The data must remain valid between invocations of the
>> application and rebooting the system.
>>
>> 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.
> My question is: how should we interpret this with respect to top-level
> *directories* in /var/cache? The spec says "files... may be expired,"
> but of course on UNIX everything is a file -- especially directories.
> Can top-level directories be deleted without warning, too?
No, i think you are reading too much into this particular wording.
The purpose of the FHS is to specify what should be stored in which
places. So what is being said here is that application files that
the application uses for caching purposes and that the application
can readily regenerate when they are manually deleted should be
stored below /var/cache.
Setting up detailed requirements for the behaviour of application
programs is beyond the scope of the FHS in the first place IMHO.
For example, despite this wording in the FHS, i would consider it
perfectly resonable for an application to require the system
administrator to stop the application before they are allowed to
tamper with its cache at all (if the application documents it that
way), or for a package manager to own certain directories which
must not ever be deleted.
Also note that the FHS is not Linux-only but applies to Unix-like
systems in general. In OpenBSD, for example, there are several
directories below /var/cache/ that the system administrator must
not delete because they belong to the package manager:
$ pkglocate /var/cache
xbase66:/var/cache
xbase66:/var/cache/fontconfig
freeipmi-1.6.3p1:sysutils/freeipmi:/var/cache/ipmimonitoringsdrcache/
freeipmi-1.6.3p1:sysutils/freeipmi:/var/cache/ipmiseld/
gdm-3.32.0p0:x11/gnome/gdm:/var/cache/gdm/
ibus-1.5.5p15:inputmethods/ibus:/var/cache/ibus/
icinga2-2.10.5p0v0:net/icinga/core2,-main:/var/cache/icinga2/
libvirt-1.3.5p9:sysutils/libvirt:/var/cache/libvirt/
logsentry-1.1.1p8:security/logsentry:/var/cache/logsentry/
samba-4.8.12p1:net/samba,-main:/var/cache/samba/
[... I deleted several lines from the output that add
nothing useful to this discussion ...]
> This becomes important when you consider that many applications that
> might make use of /var/cache run as an unprivileged user, and that
> /var/cache itself is writable only by the superuser. If the "foo" daemon
> runs as the "foo" user, and if it wants to utilize /var/cache, the
> natural thing to do is to create /var/cache/foo as root, and give
> ownership of it to the "foo" user.
Very reasonable indeed.
> But as a packager or administrator, when do I do that? If the "foo"
> package creates the directory, then it gets created once, when the
> package is installed.
Yes, do that. KISS.
> If /var/cache/foo may then be deleted, we have a problem.
I don't think the FHS authorizes system administrators to forcefully
break their system. Even when following the FHS, you still need to
pay attention to the documentation of the software you are using,
in this case the package manager.
> The alternative is to treat /var/cache like we do /run, and to
> require the service manager (systemd, OpenRC, etc.) to create the
> directory at some point with the correct ownership. This is also
> problematic if the directory can be deleted -- it only gets recreated
> when the server is rebooted.
[...]
Right, this would cause massive complication without even solving
the imagined issue: some application may not need a service manager
in the first place, may not even support being handled by a service
manager, and may support simply being started on demand from the
command line. Also, i don't think there is an issue to be solved
in the first place.
> Thus my common sense tells me that maybe top-level directories should
> not be deleted, but it's unclear if I'm justified in that belief. And of
> course, not everyone agrees -- currently, everyone picks their own
> interpretation and runs with it.
I wouldn't even restrict that to the top level directory.
If, for example, a system wanted to provide caches for a given
family of applications, i would consider it perfectly reasonable
for the package manager to own the directories
/var/cache/familyname/appname1/
/var/cache/familyname/appname2/
/var/cache/familyname/...
Yours,
Ingo
_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
