3 ms·

If you're opening with O_CREAT|O_EXCL, why does it matter whether the filename is predictable?

kijin 2y ago
Because other processes can periodically check whether a predictable filename is in use, and guess things you'd rather keep private?
- johnisgood 2y ago
  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.).
- josephcsible 2y ago
  But you wouldn't need to guess names to do that, since the names of files in /tmp are publicly listable.
fanf2 2y ago
Denial of service, the next point in that list.
cryptonector 2y ago
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).

Because other processes can periodically check whether a predictable filename is in use, and guess things you'd rather keep private?

johnisgood 2y ago
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.).
josephcsible 2y ago
But you wouldn't need to guess names to do that, since the names of files in /tmp are publicly listable.

fanf2 2y ago

Denial of service, the next point in that list.

cryptonector 2y ago

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).