1. Introduction
By default, Linux, like any multi-user operating system, reserves many operations for privileged users. Most of the time, we don’t need to bother changing this. However, there are some situations in which we have to surrender a few privileges to regular users. In this tutorial, we’ll discuss one of these situations: when there is a need to mount file systems without root privileges.
As a rule of thumb, we should never surrender root privileges (nor its password) to any user or application that does not need them. The best approach, from a security point of view, is to restrict the rights to a minimum. That is why knowing when and how we can yield any privilege to users is essential.
2. Basic Concepts
First, let’s review some concepts. For the beginner Linux admin, usually coming from a Windows or Mac OS background, the concept of mounting a file system may sound strange. A mount operation is an act of making the file system available to use. It serves for local, directly plugged drives and remote shares.
Desktop-oriented operating systems, like Windows, Mac OS, and some Desktop-oriented Linux distributions (Ubuntu Desktop, for example), assume that whenever a supported file system is detected or found, it should be made ready for use and mounted automatically if possible.
Linux servers, on the other hand, like almost all Unixes (Mac OS is a prominent exception), take the other route. All file system mount rules must be expressly defined. That approach forces the administrator to decide the options and configurations that will apply to any file system.
By the way, there are a lot of alternatives for mounting file systems. The more usual are:
- ad-hoc using the command mount or fusermount
- automatically at the boot using the /etc/fstab file
- automatically when a device is plugged in using automount
- automatically during the user login using the pam-mount module
A root user has to configure any form of automated mounts so that the mount operations themselves start without any direct user interaction. The general command syntax to mount ad-hoc mount any file system is:
# mount -o <options> <file system pafh> <mount point>
3. Mount a File System Without Root Privileges Using Sudo
At first**, a common misunderstanding is to think that only users with root rights can mount a file system. That misconception is reasonable, as the default is to deny mounting to regular users.**
That is also why the first impulse we may have is to simply add the user rights to mount and umount file systems using sudo. We can give broad rights to any device or specify the exact command line the user may use by adding the rights to the /etc/sudoers file (note, always use the command visudo to edit the sudoers file):
user1 ALL=(root) /usr/bin/mount, /usr/bin/umount
user2 ALL=(root) /usr/bin/mount /dev/sdb1 /mnt, /usr/bin/umount /dev/sdb1
The first line of the configuration gives user1 the ability to mount and unmount any device to any mounting point as the root user. The second gives user2 the right to mount that exact command line, meaning mount device /dev/sdb1 on the /mnt mount point, as well as unmount it.
The main issue of this approach is that the effective permissions on the mounted file systems will default to the root user. To be honest, we can add to the sudoers file the full options that the users can use and even use regular expressions to have finer control. Also, as with any sudo directive, we can give privileges to users and groups of users. Or configure it to accept the command without the need for the user’s password.
4. Mount a File System Without Root Privileges by Changing the Fstab File
Another approach is to add some options to the /etc/fstab file. As we saw, this file contains the known file systems, local or remote, that the system may need to mount. It’s basically a list of file systems specification entries. One file system per line, and each line has six columns separated by spaces or tabs. Also, comments are possible in lines starting with a # (sharp) character.
The sample below shows a sample /etc/fstab file excerpt with two file systems that allow non-root user mounts:
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=ROOT / ext4 defaults,errors=remount-ro 0 1
UUID=87E0-2A78 /boot/efi vfat defaults,umask=007 0 1
/swapfile none swap sw 0 0
/dev/sdb1 /mnt auto rw,owner,noauto,exec,utf8 0 0
//server/media /media cifs credentials=/etc/creds,noexec,uid=1000,user,noauto 0 0
The first, with the directive owner in the options, will only allow the user who owns the mounting point (and root users) to mount or dismount. The last, with the user option, will allow any user to mount or unmount the file system at will.
So, as we can see, any restriction we want to apply should be on the options. There are some quite common options that we will want to highlight. Note that some are dependent on the file system type:
- exec / noexec – allows or disallows executable files
- uid / gid – effective user id or group id numbers to set as the owner of the mounting points
- umask / dmask / fmask – octal bitmask to apply on the permissions for everything, directories or files, respectively
- mode – the default octal permission mode to use on the file system’s objects
There are quite a number of mount options that may apply; for a comprehensive list, we can check its man pages.
5. Mounting at the User Level – fusermount
One special case is fusermount. The FUSE system was developed to allow pluggable user-space-level file system drivers. Once the kernel has built-in FUSE support, new file system types can be added without the need to compile kernel modules. A very useful concept, indeed.
Although it is not a general rule, many FUSE file systems can be mounted by regular users without any need for additional configuration. For instance, if we have the sshfs installed, provided he owns the mount point and has valid credentials on the remote system, non-root users can mount folders in remote systems just by using:
$ sshfs <user>@<host>:<folder> <mount point>
Actually, as long as the fuser module being used does not need root access to any resource, chances are that regular users can mount it without root rights.
6. Conclusion
In this tutorial, we reviewed some of the techniques to allow non-root users to mount file systems. This can be useful in a number of situations. But note that, in practice, allowing a regular user to mount a file system may open the door to vulnerabilities.
So we should use it with some care and discretion. For instance, the mounted file system could have malicious or unwanted programs that otherwise we would not allow. In general, we might want to give users just the exact privileges they need to fulfill their roles.