Why does mount require root privileges?

Question

Why does Linux require that a user be root/using sudo/specifically authorized per mount in order to mount something? It seems like the decision as to whether to allow a user to mount something should be based on their access rights to the source volume/network share and to the mount point. A couple of uses for non-root mounting are mounting file-system images to a user owned direction and mounting a network share to a user owned directory. It seems like if the user has control over both sides of the mount equation everything should be cool.

Clarification of access restriction:

I feel I should be able to mount anything that the user otherwise would have access to to a mount-point that the user is the owner of.

For instance, on my computer /dev/sda1 is owned by user root and group disk with permissions brw-rw----. Therefore non-root users can't mess with /dev/sda1 and clearly mount shouldn't allow them to mount it. However if the user owns /home/my_user/my_imagefile.img and mount point /home/my_user/my_image/ why shouldn't they be able to mount that image file on that mount point with:

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

As kormac pointed out there is a suid problem. So some restrictions would have to be added to prevent suid from being a problem as well as potentially some other issues. Perhaps one way to do this would be to make the OS treat all files as belonging to the user that did the mounting. However for simple read/write/execute, I don't see why this would be a problem.

Use case:

I have an account in a lab where my home space is restricted to 8GB. This is tiny and very very annoying. I would like to mount an nfs volume from my personal server to essentially increase the amount of room that I have. However, because Linux does not allow such things I'm stuck with scp'ing files back and forth to stay under the 8GB limit.

Answer 1

It's both a historical and security restriction.

Historically, most drives weren't removable. So it made sense to restrict mounting to people who had legitimate physical access, and they would likely have access to the root account. The fstab entries allow administrators to delegate mounting to other users for removable drives.

From a security point of view, there are three major problems with allowing arbitrary users to mount arbitrary block devices or filesystem images at arbitrary locations.

• Mounting to a non-owned location shadows the files at that location. For example: mount a filesystem of your choice on /etc, with an /etc/shadow containing a root password that you know. This is fixed by allowing a user to mount a filesystem only on a directory that he owns.
• Filesystem drivers have often not been tested as thoroughly with malformed filesystem. A buggy filesystem driver could allow a user supplying a malformed filesystem to inject code into the kernel.
• Mounting a filesystem can allow the mounter to cause some files to appear that he would not otherwise have permission to create. Setuid executable and device files are the most obvious examples, and they are fixed by the nosuid and nodev options which are implied by having user in /etc/fstab.
  So far enforcing user when mount is not called by root is enough. But more generally being able to create a file owned by another user is problematic: the content of that file risks being attributed by the purported owner instead of the mounter. A casual attribute-preserving copy by root to a different filesystem would produce a file owned by the declared-but-uninvolved owner. Some programs check that a request to use a file is legitimate by checking that the file is owned by a particular user, and this would no longer be safe (the program must also check that the directories on the access path are owned by that user; if arbitrary mounting was allowed, they would also have to check that none of these directories are a mount point where the mount was created neither by root nor by the desired user).

For practical purposes, it is possible nowadays to mount a filesystem without being root, through FUSE. FUSE drivers run as the mounting user so there is no risk of privilege escalation by exploiting a bug in kernel code. FUSE filesystems can only expose files that the user has the permission to create, which solves the last issue above.

Answer 2

If a user has direct write access to a block device, and can mount that block device, then they can write a suid executable to the block device, mount, it, and execute that file, and thus, gain root access to the system. This is why mounting is normally restricted to root.

Now root can allow normal users to mount with specific restrictions, but he needs to make sure that if the user has write access to the block device, that the mount disallows suid, and also devnodes, which have a similar problem ( the user can craft a devnode that gives them write access to an important device they shouldn't have write access to ).

Answer 3

It doesn't always require super privs. From man mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

Answer 4

Kormac and others have indicated that this is not the dilemma you present it as; it seems to me this comes down to philosophy of explicitly granting users privileges vs. a system whereby all users would have the immutable right to mount a filesystem.

Gilles addresses some of the security problems associated with mounting filesystems. I'll retroactively avoid a prologed and tangential discussion about potential technical issues related to this (see comments) but I do think it is fair that untrusted users not have an immutable right to mount hard drives.

The issue with regard to virtual and remote filesystems (or remote filesystems via virtual filesystems, a la FUSE) is less significant, but this does not solve the security question (although FUSE might, and it certainly would solve your problem). It is also important to consider that the data in such filesystems can almost always be accessed without the need for mounting a device, either through file transfer or tools which extract from images without mounting, so a system which does not allow you to mount something does not represent an insurmountable problem with regard to accessing data that you have bizarrely placed in an image file, or (more understandably) want to get from a remote system. If you have a situation where this is not the case, it might be worth while asking:

1. What is it exactly I am trying to do?

2. Where am I trying to do it?

If the administration of the system is fair, then #2 explains why #1 is impossible for you. If the administration of the system is not fair, that's politics. The solution to the problem, "My sys admin isn't fair" is not to redesign the OS so that sys admins everywhere cannot restrict users.

The system allows the super user to restrict your activities, either explicitly, or by omission ("We don't provide FUSE", etc). Privileges are one mechanism by way of which this is accomplished. It may not be nice to be told, "You don't need to do this," but if it is true...que sera...you don't need to do this. Use ftp, etc. If it isn't true, you should pester those responsible.

Answer 5

FYI: The newest kernels have "namespace" support. Ordinary users can create a namespace, and within that namespace, become root and do fun stuff like mount file-systems.

It doesn't give you "real" super-user permissions though -- you can only do what you're already allowed to do (i.e. you can only mount devices that you can already read).

See Namespaces in operation, part 1: namespaces overview, section 4.

Answer 6

Because the data on filesystem they intend to mount might compromise security of the server, or even crash it (if it was intentionally constructed that way).

Answer 7

In GNOME, gvfs does not require root for mounting remote filesystem (ftp or ssh) and gnome-mount also does not need root for mounting external storage (usb drive, CD/DVD, etc).

Most systems probably would not want to have the whole GNOME just for some remote mounting, then you can use lufs, sshfs or ftpfs.

gvfs, lufs, sshfs, and ftpfs uses FUSE to allow non-root users to mount virtual filesystem; and unlike mount's -o user, FUSE do not require the sysadmin to arrange specific mounts. As long as you have the privilege for the mount directory and to whatever resources that are needed to construct the filesystem, you can create FUSE mount.

Why does mount require root privileges?

Because mount is primarily/originally intended for local filesystem, which almost always involves a hardware.