If you ever notice a huge amount of traffic you weren’t expecting, pop on over to your /tmp, /var/tmp, and /dev/shm folder and run ls -al. You may see several root kits, a couple of exploits, and some DDOS scripts in there. It’s happened to most of us, I’d hazard to say.

My guess is that most of these exploits make it to the /tmp Secure your /tmp areas without re-partioning folder through buffer overflow attacks in php code, so, lookup “htmlentities” and be sure you’re encoding and decoding every single datum that comes into or goes out of your MySQL database. It’s a fluid situation, it’s debatable, and each case is different, but, this seems like the most likely, common, and easy exploit.

Now, as for securing the /tmp type folders, there are several good sites out there that can tell you how to do it if you have a separate disk or partition. The general idea is to create a partition with no execute permissions, then add it’s entry to fstab so that the un-executable block gets mounted as /tmp during boot.

But what if you’re already looking at someone’s production server and there’s just no room, budget, or time to add disk space and repartition the current layout? When I analyzed this exact scenario, I found what I consider a very reasonable solution that takes less time than you’ll spend reading this article to execute. What we’re going to do is make the shared memory un-executable, then point /tmp and /var/tmp to the same file system. Here’s how:

Back up the original fstab file
cd /etc
cp fstab fstab.original

Add the following entries to /etc/fstab with your favorite text editor

tmpfs /tmp tmpfs nosuid,noexec,nodev,rw 0 0
tmpfs /var/tmp tmpfs nosuid,noexec,nodev,rw 0 0
tmpfs /dev/shm tmpfs nosuid,noexec,nodev,rw 0 0

Now, the reason I say this is because I’m gambling that shm is set to 50% of the physical ram by default in most linux distros AND that when full, shm will page over to the swap partition. Therefore, on a machine with, say, 8 gigs of RAM, up to 4 Gigs of RAM to be shared amongst /dev/shm, /tmp, and /var/tmp – which when full will page over to the swap space.

Some of the people I discussed this with warned me that there might be some disk thrashing if this method was used. It is indeed possible that some amount of thrashing will occur, but in my opinion it may be less than writing to /tmp directly. Why? Because in the natural situation we are always writing to disk when we write to the /tmp folder. By pointing /tmp to shared memory, the ram will fill up first before we begin swapping out to disk.

On the machine I was working on, which as I pointed out earlier had 8 gig of RAM, I suspected that most of the thrashing, if it were to occur, would happen during the nightly backups when a huge amount of data would normally have been stored in the /tmp folder. Still, this was happening mostly at midnight UTC -7 while traffic was relatively low and at other times no thrashing at all would occur. Your mileage may very, but this is an acceptable solution on many, many boxes.

Also note another option which I did not try. It’s possible to specify the amount of RAM to be consumed before paging. You may want to make your fstab entry look like the following, editing the amount of RAM higher or lower, depending on how much RAM you can spare for /tmp space:

tmpfs /var/tmp tmpfs size=2048m,nosuid,noexec,nodev,rw 0 0

Of course, there are some detractors to this method out there. The first negative comment, which does concern me a tiny bit, but not too much, is that /var/tmp is supposed to be persistent between boots. With this fix, /var/tmp is now volatile. Still, as I said over in the virtualmin forums, “they don’t call it tmp for nothin'”. If you have an application that will fail if it loses it’s temp storage due to boot volatility, this won’t be for you.

The second negative comment is generally something like “Are you crazy? My /tmp folder is 240 MB for days at a time! Are you seriously suggesting I waste a quarter gig of RAM for generally disposable files?” In the case in question, I set up a cron job to clean the /tmp folders a little more frequently than is typical. As always, your mileage may vary. For some situations, this will be an acceptable alternative to creating a new partition or adding a new disk drive and remapping the /tmp folders.


3 Responses to “Secure /tmp, /var/tmp, and /dev/shm Without a Separate Partition”

  1. cr says:


    according to linux filesystem standards /var/tmp should not be a tmpfs filesystem. Usually /var/tmp contains files/data that should survive a server reboot. With /var/tmp setup as a tmpfs this would not be the case because it get’s deleted during server restart.


    • Anthony Lake says:

      You’re right. Not only that, but there are other minor annoyances with local clients that can crop up, (like forgetting your window and desktop preferences in the middle of a session). It’s not a perfect solution, especially if your computer is a general purpose machine; but generally, these things haven’t caused any real problems on a strictly server machine – AND – it has done an excellent job of securing the folders against those nasty php injections.

  2. Jim says:

    Any difference between /var/tmp and tmpfs?

    Recommended Powerful VPS

Leave a Reply

Switch to our mobile site