Most active commenters
  • aidenn0(3)

←back to thread

Against /Tmp

(dotat.at)
140 points todsacerdoti | 11 comments | | HN request time: 0.877s | source | bottom
1. 0xC0ncord ◴[] 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 #
2. yjftsjthsd-h ◴[] No.41914558[source]
There's also https://www.freedesktop.org/software/systemd/man/latest/syst... to do the same for services if you use systemd.
3. aidenn0 ◴[] 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 #
4. zbentley ◴[] 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 #
5. aidenn0 ◴[] No.41915197{3}[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.

6. xerxes901 ◴[] No.41915231[source]
/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 #
7. aidenn0 ◴[] No.41915244{3}[source]
Thanks!

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

8. zokier ◴[] No.41915256[source]

    nsenter --all --target $PID
or something like that?

https://man7.org/linux/man-pages/man1/nsenter.1.html

9. zokier ◴[] No.41915312{3}[source]
mount namespace and root directory are bit different things though.

/proc/$PID/ns is the place to look for namespaces

10. fanf2 ◴[] No.41915729[source]
Lovely, another layer of complexity to increase the safety of a fundamental mistake that we can no longer fix!
11. cryptonector ◴[] No.41916817[source]
If you're not using PAM then you don't get these.

For example, Kubernetes doesn't use PAM in the pods it creates to run your containers.

You might think "who cares", but I've written code that is agnostic as to whether it's running in a logged-in user's session or something else. https://news.ycombinator.com/item?id=41916623