As u/fanf says, denial of service. The canonical example here would be `/tmp/krb5cc_$UID`, which is where Kerberos libraries keep your Kerberos credentials. If you create that for some other user's UID before they login, they won't be able to use Kerberos (unless they have a clue), causing support calls. This isn't really an issue, but still.

And of course those libraries' code that uses those files had to be written very carefully.

Sure, the more modern thing is to have a daemon called `kcm` that does that and which has an AF_LOCAL socket in... /var/run/, but it's a multi-user-capable daemon, so it doesn't need /var/run/user/${UID}, which as I've noted elsewhere here, is not universally available (for the same reasons that /run/user/${UID} is not either).

Denial of service, the next point in that list.

Why would you have processes you do not trust, or why not use firejail for those that may pose a security risk?

> Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf and Linux capabilities. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table. Firejail can work in a SELinux or AppArmor environment, and it is integrated with Linux Control Groups.

It supports "--private" (mounts new /root and /home/user directories in temporary filesystems), along with "--private-{bin,cache,cwd,dev,etc,home,lib,opt,srv,tmp} (plus "noexec /tmp")". It also supports "keep-config-pulse", "keep-dev-shm", and so forth, meaning you can have shared files between process if you so wish (for DBus, etc.).

But you wouldn't need to guess names to do that, since the names of files in /tmp are publicly listable.