Hacker News Reader

Comment by cryptonector | Hacker News Reader

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.

View on HN

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

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

As an obvious example: You should not trust your browser to have access to all of your file system(s) without explicitly allowing at the time of access. The only thing it should (usually) have access to is your "Downloads" folder... and that's about it.

Browser security would be a lot less time-sensitive if that were the case.

The same logic applies to games, etc. etc. I do NOT trust the developers of these things to get things right 100% of the time, so why even take the risk of allowing their programs unfettered access to all of my files? As a dev, I don't even trust myself to be perfect and I'd like to be able (in my program) to state up from "my code will never touch anything outside Downloads/" or whatever.

ETA: The point is minimal trust for any given program to do its thing. I'd like to be even more pithy with something about "trust but verify", but that doesn't quite fit, alas.

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.

Sure, POSIX is basically Unix as standardized over several decades. Unix is 54 years old. Containers are a very recent development. POSIX is behind. But you do have the option to use containers/jails/zones, it's just not POSIX. What does any of that have to do with TFA?

I just wanted to point out that some unixoid systems (even some who are actually UNIX certified, but that's not really relevant to the issue) employ protection of temporary files stronger than what was suggested in TFA. The containers/jails/zones that you mention are an example of this.

Does k8s guarantee that /tmp is available either?

Well, I suppose that depends on the images you choose to run, and how you choose to build them, but I've never seen one that didn't have a /tmp. Have you?

Sure, all `FROM scratch` images for starters

Reply on news.ycombinator.com