In the previous post I’ve written the why and how of private temporary directories with the pam_mktemp module. Today I’m going to present you the alternative – pam_namespace – and discuss its problems.
Since all software tries to write to /tmp, the idea implemented by pam_namespace is that of providing a different directory for each user, so you can have private per-user temporary directories without messing with the environment variables, or having to change code. This creates, though, a few problems: some software still uses the temporary directory for multi-user sockets (luckily, nothing major in Gentoo that I know of, PostgreSQL was changed already), but most importantly, the polyinstantiation session that is used by pam_namespace to achieve its results restricts mounts to be available only on that particular session.
What does that mean? Well, let’s say you are logged in as a standard user in the system, you have to mount some partition that is by default unmounted (for security, or because it’s used for backups or stuff like that). To mount it you su to root, and run mount; you check the partition is mounted and it’s okay. You exit from the super user shell and… the mount point is empty. Why? Because the su session is the only one that could have seen that mount. This gets extended to extreme consequences when you use hotplug and automount systems, like HAL, or even more DeviceKit (the latter because it opens a new session for each mount), or when you use sudo mount to try mounting a partition (where the session is opened and closed right away).
So what are our currently available mitigation options? It really depends, because we have no valid “catch-all” option: if you run a desktop system where you don’t need samba, you can have a (light) mitigation by using pam_mktemp; if you run a server system with no hotplug, you might want to try the pam_namespace approach (which isn’t really ready for Gentoo integration yet). What we’d really need is something that uses the pam_namespace approach, but only dissociates the /tmp directory rather than the whole system).
The other alternative, easier, with better results on the long run, and most importantly not tied to Linux, would be to actually make it policy that software in Gentoo works by writing to TMPDIR and not /tmp, and make sure that /tmp cannot be written to at all. Unfortunately this might require some Gentoo-side patching because upstream don’t always accept this request (see my GnuPG notes), and fixes for, at least, Samba to properly change the CWD.
Interesting series of blog posts. Currently I’m dealing with nearly an identical problem, although from a different perspective. On the cluster I manage we use diskless nodes and mount /tmp as a tmpfs. The problem becomes that as jobs run on the cluster, some of them dump junk in /tmp that doesn’t necessarily get cleaned up (either because of sloppy code, or because the program might crash, run out of memory, etc) which eventually causes /tmp and thus the system memory to fill up. The solution is of course to provide a per-job directory that gets deleted after the job completes. Fortunately Torque/PBS supports this feature, it will create /tmp/<jobname> for each job and set TMPDIR appropriately. Now it’s just a matter of forcing all the software that the developers write and the users use to honor TMPDIR instead of hard-coding /tmp as a temporary path.