Against /Tmp

(dotat.at)

Show context

0xC0ncord ◴[22 Oct 24 13:20 UTC] No.41913968[source]▶

>>41913610 (OP) #

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 #

1. aidenn0 ◴[22 Oct 24 14:56 UTC] No.41914916[source]▶

>>41913968 #

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 #

2. zbentley ◴[22 Oct 24 15:07 UTC] No.41915034[source]▶

>>41914916 (TP) #

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 #

3. aidenn0 ◴[22 Oct 24 15:23 UTC] No.41915197[source]▶

>>41915034 #

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.

4. xerxes901 ◴[22 Oct 24 15:26 UTC] No.41915231[source]▶

>>41914916 (TP) #

/proc/PID/root is a view of that process’s mount namespace.

Also you can use nsenter(8) to run a command (or even a shell) under another process’s mount, pid, network, etc namespace.

replies(2): >>41915244 #>>41915312 #

5. aidenn0 ◴[22 Oct 24 15:28 UTC] No.41915244[source]▶

>>41915231 #

Thanks!

It's exactly what I was looking for, and the world can now continue to improve without breaking any of my workflows :)

6. zokier ◴[22 Oct 24 15:28 UTC] No.41915256[source]▶

>>41914916 (TP) #