After seeing what the Wildfly (formerly JBoss AS) and Liferay combo does to /tmp, and somewhat attempting to fix it, I saw JVM_TMP in the Debian tomcat7 init script and thought, oh no, not another one.

Is that even safe, what they do here, or is that a possibility to instantly pwn?

The net is full of literature for how to obtain temporary files and directories, but there is nothing about how to reliably obtain paths under /tmp or, more generally, directories not just writable for one single user (think the g+w thing that got FusionForge CVE-2013-1423).

The scenario here is: I am root, and I want to start something as another user, and pass it a stable path, such as /tmp/liferay. So I can just mkdir /tmp/liferay || die; chown thatuser /tmp/liferay and, in the “stop” process, rm -rf /tmp/liferay, right? (Of course not. Also, bad example, as the liferay thing can also be started as thatuser, and our devs regularily need to do that, the init script is there just for the admin convenience and reboot-safety. But I still am interested if there is a secure way to achieve this.)

The tomcat7 scenario is “trivial”: on That Other Init System™, it would just get its private /tmp declared in the .service file, and good is, no more hassle. That's one I have to give you. (No idea if this is actually shipped in jessie. Our production systems run wheezy anyway, so there is not even the slightest bit of temptation. Plus, it would not solve the liferay issue, see above. Still, a point for going into the right direction.)

The idea here is the same. It creates a directory on start and tears it down on stop. If there was nothing to do on start, the init script could just use mktemp -d. Heck, maybe it still should, but it would need to note down, and communicate to the stop instance, the actual name used. What a drag…

This is something I see popping up from time to time. I want to use stable paths for SSH session multiplexing control sockets in my ssh_config(5) file, but have them on tmpfs (Linux) or mfs (BSD) so they get properly removed on reboot. No Unix traditionally has per-user temporary directories that are clean and created after reboot. (Adjusting the paths is trivial once you have them.) Android has it worse, what with not having a world-writable tmp directory, which the shell needs e.g. for here documents; there are two components here, to have a directory the current user can write to, and to know its location. Some fail at the first, some at the second, some at both, and the classic /tmp is not the cure, as we have seen. (But if you ever see mksh erroring out due to lack of write permissions somewhere (including /sqlite_stmt_journals which used to be it) as non-root on Android, or even as root, set TMPDIR to something writable; it's tracked, so the change gets active immediately.)