site_cache_dir: Use `/var/cache` again instead of `/var/tmp` on UNIX

[andersk]

This directory was changed from /var/cache to /var/tmp in #148 due to permissions issues. However, /var/tmp is an insecure location to store anything with a predictable filename, because any other user could have written it first. This leads to vulnerabilities categorized under CWE-377 and CAPEC-149.

To deal with the permissions issues, applications should put their own cache data in a subdirectory of /var/cache (e.g. /var/cache/cups), and the application’s package is responsible for ensuring the subdirectory exists and giving it the correct permissions.

[efiop]

site_cache_dir on both windows and mac are writable by regular users, while /var/cache is not, so this change will break applications that are not using elevated privileges. That seems unexpected and inconsistent in the practical sense.

Maybe this should be a new opt-in option?

[efiop]

This directory was changed from /var/cache to /var/tmp in #148 due to permissions issues. However, /var/tmp is an insecure location to store anything with a predictable filename, because any other user could have written it first. This leads to vulnerabilities categorized under CWE-377 and CAPEC-149.

Please correct me if I'm wrong, but seems like permissions of the base dir (/var/cache vs /var/tmp) don't really prevent users from creating those vulnerabilities, as they still need to handle file permissions correctly when creating files/subdirs. But using /var/cache makes it so that no regular user can create anything in /var/cache without additional privileges, thus forcing the application to be installed with sudo, which is inconsistent with site_cache_dir on other platforms.

[andersk]

@efiop On Windows, C:\ProgramData is only writable by administrators. I’m not familiar with the expectations regarding /Library/Caches on macOS. (I note there’s a /System/Library/Caches only writable by root.)

On Unix, a subdirectory of /var/cache will not be writable by other users unless you explicitly set it up that way. The goal here is not to make it impossible to explicitly write vulnerabilities; the goal is to avoid introducing them implicitly.

[efiop]

Good point about ProgramData.

Indeed, looks like I'm in the wrong here.

Not sure if platformdirs has a procedure for breaking changes like this. We'll need some help from maintainers here.

[gaborbernat]

Because this is a fairly recent feature, I am okay too. Make this change now. I might make it a new major release just in case. But please feel free to go ahead.

[efiop]

A major release would indeed be great and would allow us to migrate gracefuly.