Allowing anyone to mount any filesystem at any location would open a number of security holes.
- An obvious one is that the filesystem driver gets to access the underlying device. This may be hardware that the system administrator does not want to expose to users.
- Another obvious one is that there may be files that allow users to gain privileges. A setuid root shell, for example. Or a device node that allows raw access to the memory or disk or other hardware resource. Allowing a user to mount an arbitrary filesystem allows him to create arbitrary setuid/setgid programs and device nodes.
- A more subtle issue is that mounting a filesystem might create files in an unexpected location. Some applications read files in fixed locations, or trust files where the chain of directories from the root to the file is entirely owned by one user. Mounting a different filesystem along the path could allow the mounter to replace legitimate files by arbitrary content. For example, you could then mount a copy of
/etc with a different
passwd file with a root password set by you. Or you could mount a different directory on top of a user's home directory and provide your own
- Another concern is that filesystem drivers are often written for performance and reliability with well-formed filesystems. If a filesystem is malformed, it may trigger a bug in the driver that allows whoever controls the underlying device to execute code in the context of the filesystem driver, which traditionally runs in the kernel.
You can declare a device, mount point and mount options in
/etc/fstab to mount a filesystem automatically at boot time. It's up to the system administrator not to put anything “dangerous” there, for example no mounting of unknown filesystems in system locations, disable setuid except on the root filesystem, etc.
The old-fashioned way of allowing ordinary users to mount transient filesystems is to put the
user mount option on an fstab, typically combined with
user automatically implies three other options:
noexec. These options disable setuid/setgid files (those bits have no effect), device files (device nodes have no effect), and executable files (the executable bit is ignored except on directories) respectively. The
nodev options are critical;
noexec can be disabled (by adding
user) in almost all situations. Here's a typical fstab line for a removable device:
/dev/cdrom /media/cdrom iso9660 noauto,user,exec
A more modern method to allow users to mount removable devices is to install the
pmount program. This program has more flexible policies than fstab, which only allows a predefined list. Pmount enforces several constraints, including requiring that the device be declared as removable and the mount point be an empty directory under
For network resources, the traditional approach to go beyond a predefined list is an automounter. The automounter is typically configured to allow users to mount only network filesystems (NFS, Samba), only from vetted hosts (or at least only inside a domain), with predefined options including
A more modern approach to allowing users to mount filesystems is to move the filesystem driver out of the kernel. FUSE is the de facto standard here (on Solaris, Linux, *BSD, OSX). The user must have access to the underlying device (if any) since all device accesses are performed by an unprivileged process. For the same reason, a bug in the filesystem driver will not compromise the security of the operating system. The user must own the mount point, so he will not be able to make files appear where he could otherwise not make files appear. Setuid and setgid bits are ignored. It is, however, possible to make files be owned by any user, no just the user doing the mounting.