Product SiteDocumentation Site

4.10. Mounting partitions the right way

When mounting an Ext file system (ext2, ext3 or ext4), there are several additional options you can apply to the mount call or to /etc/fstab. For instance, this is my fstab entry for the /tmp partition:
  /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2
You see the difference in the options sections. The option nosuid ignores the setuid and setgid bits completely, while noexec forbids execution of any program on that mount point, and nodev ignores device files. This sounds great, but it:
  • only applies to ext2 or ext3 file systems
  • can be circumvented easily
The noexec option prevents binaries from being executed directly, but was easily circumvented in earlier versions of the kernel:
  alex@joker:/tmp# mount | grep tmp
  /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
  alex@joker:/tmp# ./date
  bash: ./date: Permission denied
  alex@joker:/tmp# /lib/ ./date
  Sun Dec  3 17:49:23 CET 2000
Newer versions of the kernel do however handle the noexec flag properly:
  angrist:/tmp# mount | grep /tmp
  /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
  angrist:/tmp# ./date
  bash: ./tmp: Permission denied 
  angrist:/tmp# /lib/ ./date 
  ./date: error while loading shared libraries: ./date: failed to map segment 
  from shared object: Operation not permitted
However, many script kiddies have exploits which try to create and execute files in /tmp. If they do not have a clue, they will fall into this pit. In other words, a user cannot be tricked into executing a trojanized binary in /tmp e.g. when /tmp is accidentally added into the local PATH.
Also be forewarned, some script might depend on /tmp being executable. Most notably, Debconf has (had?) some issues regarding this, for more information see
The following is a more thorough example. A note, though: /var could be set noexec, but some software [15] keeps its programs under in /var. The same applies to the nosuid option.
/dev/sda6   /usr          ext3    defaults,ro,nodev       0       2
/dev/sda12  /usr/share    ext3    defaults,ro,nodev,nosuid        0       2
/dev/sda7   /var          ext3    defaults,nodev,usrquota,grpquota 0      2
/dev/sda8   /tmp          ext3    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
/dev/sda9   /var/tmp      ext3    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
/dev/sda10  /var/log      ext3    defaults,nodev,nosuid,noexec    0       2
/dev/sda11  /var/account  ext3    defaults,nodev,nosuid,noexec    0       2
/dev/sda13  /home         ext3    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
/dev/fd0    /mnt/fd0      ext3    defaults,users,nodev,nosuid,noexec      0       0
/dev/fd0    /mnt/floppy   vfat    defaults,users,nodev,nosuid,noexec      0       0
/dev/hda    /mnt/cdrom    iso9660 ro,users,nodev,nosuid,noexec            0       0

4.10.1. Setting /tmp noexec

Be careful if setting /tmp noexec when you want to install new software, since some programs might use it for installation. apt is one such program (see if not configured properly APT::ExtractTemplates::TempDir (see apt-extracttemplates(1)). You can set this variable in /etc/apt/apt.conf to another directory with exec privileges other than /tmp.

4.10.2. Setting /usr read-only

If you set /usr read-only you will not be able to install new packages on your Debian GNU/Linux system. You will have to first remount it read-write, install the packages and then remount it read-only. apt can be configured to run commands before and after installing packages, so you might want to configure it properly.
To do this modify /etc/apt/apt.conf and add:
      Pre-Invoke  { "mount /usr -o remount,rw" };
      Post-Invoke { "mount /usr -o remount,ro" };
Note that the Post-Invoke may fail with a "/usr busy" error message. This happens mainly when you are using files during the update that got updated. You can find these programs by running
# lsof +L1
Stop or restart these programs and run the Post-Invoke manually. Beware! This means you'll likely need to restart your X session (if you're running one) every time you do a major upgrade of your system. You might want to reconsider whether a read-only /usr is suitable for your system. See also this discussion on debian-devel about read-only.

[15] Some of this includes the package manager dpkg since the installation (post,pre) and removal (post,pre) scripts are at /var/lib/dpkg/ and Smartlist