←back to thread

Against /tmp

(dotat.at)
257 points todsacerdoti | 1 comments | 22 Oct 24 12:36 UTC | HN request time: 0.239s | source
Show context
scottlamb ◴[22 Oct 24 15:25 UTC] No.41915221[source]▶
> There should be per-user temporary directories. In fact, on modern systems there are per-user temporary directories!

On Linux+systemd, I think this is referring to /run/user/$UID. $XDG_RUNTIME_DIR is set to this path in a session by default. There's a spec for that environment variable at <https://specifications.freedesktop.org/basedir-spec/latest/>. I assume there's also some systemd doc talking about this.

On macOS, I see that $TMPDIR points to a path like /var/folders/jd/d94zfh8d1p3bv_q56wmlxn6w0000gq/T/ that appears to be per-user also.

What do FreeBSD/OpenBSD/NetBSD do?

replies(4): >>41916623 #>>41918825 #>>41918913 #>>41919219 #
cryptonector ◴[22 Oct 24 17:34 UTC] No.41916623[source]▶
Unfortunately /run/user/$UID/ is NOT universally available.

On Linux it's typically created by a PAM, so if you're not using PAM then it doesn't exist. This means that on Kubernetes pods/containers... it doesn't exist!

Yes, /tmp/ is a security nightmare on multi-user systems, but those are a rarity nowadays.

Lots of things want to write things into /tmp, like Kerberos, but not only. I recently implemented a token file-based cache for JWT that... is a lot like a Kerberos ticket cache. I needed it because the tokens all have specific aud (audience) values. Now where to keep that cache?? The only reasonable place turned out to be /tmp/ precisely because /run/user/$UID/ is not universally available, not even on Linux.

replies(2): >>41918393 #>>41918782 #
anyfoo ◴[22 Oct 24 21:15 UTC] No.41918782[source]▶
> Yes, /tmp/ is a security nightmare on multi-user systems, but those are a rarity nowadays.

What's not a rarity though is apps (or code in general) that you don't fully trust, and that you don't want to give a chance to exfiltrate all your data for example.

Sadly, the POSIX permission model is entirely ill-suited for that, precisely because it tries to solve the multi-user problem, wherein all code belonging to a single user is effectively treated omnipotent within that user's domain (i.e. the files the user owns). That's why iOS and macOS (the non-POSIX parts) has a container model with strong sandboxing, entitlements, etc.

replies(2): >>41919101 #>>41919141 #
eikenberry ◴[22 Oct 24 21:52 UTC] No.41919101[source]▶
> What's not a rarity though is apps (or code in general) that you don't fully trust, and that you don't want to give a chance to exfiltrate all your data for example.

How many of these do you have? I have 1 and I have it installed via a flatpak with sandboxing (that has no access to /tmp).

Flatpak's are an implementation of that container model for software on Linux.

replies(2): >>41919157 #>>41919243 #
1. anyfoo ◴[22 Oct 24 22:09 UTC] No.41919243[source]▶
On my phone? Tons. My phone has a boatload of data, and I readily install apps. I don't want one rogue update of a rarely used app (supply chain attacks are very real as we know) to get access to all my text messages and email, or to whatever my banking apps keep as state.

On my Mac? Less, but it happens. But text messages, photos, and the banking apps installed there etc. are still inaccessible by anything except the thing's I've explicitly given access.