Linux Securing your /tmp directory

its recently been noted that lots of people having there servers hacked because they were running vulnerable versions of PHPMyAdmin. obviously the best advice to fix this is to upgrade your PMA install to the latest version or to otherwise protect it with passwords etc (apache passwords not just the db passwords). however this may not always be totally feasible or possible (i am looking at ISPManager Pro installs on debian here mostly)

this is a very short guide that will help you secure your server by locking down the tmp directory more thoroughly and thus hopefully effectively eliminating the access point that this exploit uses.

DISCLAIMER – this does not close the exploit that PMA is open to, it just closes the access point for it, there is still possiblity for it to gain access via other as yet unknown means.
ALSO – messing up your fstab file can lead to an unbootable system, you should make a system backup before making such a change or be able to boot into some form of recovery enviroment to be able to re edit the file to fix

the fix is pretty simple to implement and involves making your server’s tmp directory get mounted with no executable permissions (noexec) or no sticky user id bit settings (nosuid) which is where the exploit does its damage – it executes code from the tmp directory which normally has global write access of some sort, this guide is tested to work with debian systems (with or without ispmanager pro) and should also work on CentOS systems with no issues, see my caveats at the bottom for cpanel servers.

firstly login to your server as root via ssh (or console) if you dont ssh as root, connect as you normally do and get to root level access (you may need to add sudo to the beginning of your commands) – i am assuming you have root access from now on and nano (choose your own text editor if you are more comfortable with it eg vi)

we need to edit fstab to make the temp directory noexec and nosuid, we do this by editing the fstab and using a bind mount to effectively remount a directory as a partition (this is used to often remount folders and make them accessible from different points eg making the folder /bob available at /bobby as a partition (not just a folder/symlink) to do this:

nano /etc/fstab

your text editor will come up now, if you are familiar with the syntax it goes:

<device> <mountpoint> <filesystemtype><options> <dump> <fsckorder>

if you have a line that has /tmp in the second collumn, see my caveats below, otherwise add the following line to your fstab file:

/tmp  /tmp  bind  nosuid,noexec,bind  0  0

this effectively makes the /tmp folder on / (the root partition) available as a partition mounted at /tmp – you can do lots of cool things by mounting other directories over others but thats way beyond the scope of this guide

to make this take effect you can either reboot your server with:


or whatever command/process you do to reboot

or if you are happy to unmount and remount (i dont normally reccomend this for safety sake)

umount /tmp
mount -a


if your fstab file already has a line with /tmp in the second collumn (eg most reasonably up to date cpanel servers) then just simply adding this line will most likely cause issues, you should simply edit the existing line and add the options


to the flags section

eg a default cpanel temp dir line may look like this:

/usr/tmpDSK  /tmp  ext3  defaults,noauto  0 0

just add the flags to make it look similar to:

/usr/tmpDSK  /tmp  ext3  defaults,noauto,noexec,nosuid  0 0

NOTE: nano tends to wrap text when you edit if your window is small and the fstab file is very very sensitive to this and will cause problems if each non commented line is not a fully syntactically correct line. To avoid this issue, either maximise your shell window or load nano in non wrapping mode (-w) eg

nano -w /etc/fstab

again unmounting and remounting or rebooting your server will pickup these new settings

2 thoughts on “Linux Securing your /tmp directory

  1. CalonDdraig

    It’s funny that you should blog this at this time, because I know a fair few people who’ve been affected by this, myself included.

    I presume that the most prudent action is to update PMA? Though of course, the changes to mounting /tmp are very useful – I used them on my box.

    It’s funny, people tend to forget about PMA… I was too busy making sure our CMS is up to date, upgrading everything through apt, kernels, … tearing hair out… that I didn’t notice the version of PMA we were using was almost 2 years old:)

    Thanks for a great and very helpful post!


    1. Anthony Somerset Post author

      yes it is important to keep PMA up to date as well, but sometimes its not always possible (eg debian package is at 2.2ish) in that case i would much rather recommend uninstalling debian’s version and manually installing it on a protected vhost (http authentication from apache) and with the mysql auth too via cookie and use an ssl domain (even if using a self signed cert)

Comments are closed.