←back to thread

Against /Tmp

(dotat.at)
140 points todsacerdoti | 2 comments | 22 Oct 24 12:36 UTC | HN request time: 0s | source
Show context
0xC0ncord ◴[22 Oct 24 13:20 UTC] No.41913968[source]▶
I'm amazed that polyinstantiation of directories via pam_namespace.so[1] is so unheard of. Setting this up fixes almost all of the qualms mentioned in the article by giving each user their own mount namespace with an isolated /tmp directory (and others if configured). Still though, this wouldn't prevent poorly written applications using /tmp from clashing with others that are running under the same user.

It's relatively easy to set up[2] and provides a pretty huge defense mitigation against abusing /tmp.

[1] https://www.man7.org/linux/man-pages/man8/pam_namespace.8.ht...

[2] https://docs.redhat.com/en/documentation/red_hat_enterprise_...

replies(4): >>41914558 #>>41914916 #>>41915729 #>>41916817 #
aidenn0 ◴[22 Oct 24 14:56 UTC] No.41914916[source]▶
Is there an easy way to duplicate a specific process' namespace? My biggest issue with all these new features is that privatize state is how much harder it is to reproduce a state.

Back when it was just environment variables, I could pipe /proc/PID/environ to xargs and get basically the same state. Given that things like unix domain sockets may end up in $TMPDIR, I can be left unable to do certain things.

replies(3): >>41915034 #>>41915231 #>>41915256 #
1. zbentley ◴[22 Oct 24 15:07 UTC] No.41915034[source]▶
I don't think there is, or should be, a way to do that. Granular copying of per-process resource state seems like a need that would be better served at either a closer-to-the-program layer (i.e. debug hooks in code you control that provide information on how to reconstruct its state) or much further away (e.g. via CRIU/whole-machine snapshots or scary tricks like SIGSTP or ptrace-injecting calls to fork(2)).

> I can be left unable to do certain things

Most of what I can imagine of "certain things" falls into two categories: debugging (for which much better tools exist), or concerns that would be better served by a program providing an API of some kind rather than "go muck with state in $TMPDIR".

replies(1): >>41915197 #
2. aidenn0 ◴[22 Oct 24 15:23 UTC] No.41915197[source]▶
Here's a recent one; I needed to play some sound via an ssh login session. A Wayland/pipewire session was already open. I was able to do this just by copying a running processes environment. With enough containerization &c. I'll need to do more things to do that, if it's at all possible.

Also, /proc/ is (among other things) a debug interface.