59

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.

Mat
  • 52,586
CrazyCasta
  • 825
  • 2
  • 7
  • 13
  • 6
    It sounds like the problem is not so much that "linux does not allow such things" as you are not allowed to do such things at your lab, since the system could be configured to allow you to do it. You could discuss this issue with the people who administrate the system; if they aren't friendly, then it is about politics and not computers ;) – goldilocks Feb 17 '13 at 01:52
  • Is it possible to mount arbitrary mount points that one has normal access to? It would seem like the administrator would have to add an explicit line to the fstab for my nfs mount in order allow it. In turn this would likely setup a precedent where they would have to also do such for everyone else that asked for such, which I can understand would be untenable. Hence the query as to why Linux doesn't allow you to mount arbitrary things that would be safe (in some restricted fashion). – CrazyCasta Feb 17 '13 at 01:54
  • 10
    Have you tried sshfs? It'll mount a remote directory, through ssh, as yourself, without the need for root access. It just needs FUSE (Filesystem in UserSpacE) to be installed. – Arcege Feb 17 '13 at 02:06
  • 1
    You've heard about the bad hard drive issue, etc. So, I know I've said this a bunch of times, but the philosophy is that "mounting arbitrary things" cannot be made safe, and that's why it's set the way it is (specific exceptions must be arranged). BTW, if you don't have FUSE, sftp is a little nicer to use than scp. – goldilocks Feb 17 '13 at 02:09
  • @Arcege That's the kind of thing I was looking for. I had not heard of FUSE. Is there any sort of mount based on FUSE to handle more generic things (like image files and nfs)? – CrazyCasta Feb 17 '13 at 02:13
  • @goldilocks I don't think you've been paying attention. If your definition of "arbitrary things" is anything then obviously it cannot be made safe. In the same way that the operating system doesn't allow one to "arbitrarily" edit files. However if you use my definition of "arbitrary things", those things which the user can read/write then no one has offered a reason why it couldn't be made safe. – CrazyCasta Feb 17 '13 at 02:26
  • @CrazyCasta: Was about to go chill out and a more technical explanation occurred to me, I added a few paragraphs starting with "Finally", qv. Anyway, I understand you are frustrated, but also try to understand that computer systems and how they function are, in fact, not easily transparent to "lay people", and what may seem self-evident to you (eg, with regard to what is arbitrary, what is safe) may turn out to be ass-backward when you learn what is really going on. It's science, remember? ;) – goldilocks Feb 17 '13 at 02:46
  • @goldilocks You are being a patronizing jerk. I am not a lay person. I am very well versed in the device side of the kernel, I am not well versed with the mounting side of the kernel. I understand that there are reasons for restricting access to devices, which you have unnecessarily dived into very specific details on. I have not asked (as I already know the obvious answer) why access to specific device nodes are restricted. Please read and understand my comments before wasting space on non-answer explanations. – CrazyCasta Feb 17 '13 at 03:03
  • Hmph. Well, I know you don't like it, but there it is. :( Mounting == devices – goldilocks Feb 17 '13 at 03:19
  • 1
    It looks like (a variation of) this has already been asked here before: Mount a loop file without root permission? – Daniel Pryden Feb 17 '13 at 08:22
  • @CrazyCasta, NFS is its own protocol; FUSE could possibly use it beneath, but it wouldn't replace the NFS protocol. Look at the wikipedia page (http://en.wikipedia.org/wiki/Filesystem_in_Userspace#Example_Uses) and its own page (http://fuse.sourceforge.net/) to get better idea of how it might be used. – Arcege Feb 17 '13 at 15:18

7 Answers7

45

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.

Gilles 'SO- stop being evil'
  • 829,060
26

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 ).

psusi
  • 17,303
8

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.
R. S.
  • 189
  • Yes, you are correct, I was a little imprecise in my question. I am aware that one can be specifically authorized on a mount-by-mount basis. But it seems if the mount point and volume are both owned by the user that the user should be able to mount with no specific authorization. –  Feb 17 '13 at 00:39
  • 3
    @CrazyCasta: the mount point may be owned by the user, but the device node is not. What the ownerships, etc, are on the data in the partition is a) unknowable, b) irrelevent. – goldilocks Feb 17 '13 at 00:52
  • But what if the device node is owned by the user. – CrazyCasta Feb 17 '13 at 01:56
  • Then there should be a parallel exception made in fstab, since a user owned device node would be exceptional to start with (try and create one). Again, the principle is that a secure system is restricted, and people are granted privileges...if you haven't been granted privileges, you are out of luck, unfortunately. See, *nix does not sell high capacity magazines over the counter -- you need a permit. – goldilocks Feb 17 '13 at 02:01
  • 2
    To be clear, the mount() system call always requires root. suid utilities can become root and allow non root users to mount, and if the mount command is installed suid, then it will do this based on the user flag in fstab. Other suid executables have been written to allow users to mount, such as pmount, which allows users to mount external media, and enforces the appropriate restrictions, such as nosuid, nodev. – psusi Feb 17 '13 at 18:13
5

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.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
  • Your answer is confusing, are not the volumes themselves (e.g. /dev/sda1, /dev/sda2, etc.) protected from users reading/writing them? I'm wondering why a user can't mount something that they otherwise have access to. To clarify, if I have an image file that's say ext2 I could write an application that allows me to read/write from/to said image (not as part of the OS's filesystem of course). Said application would not be able to read/write from the partitions in /dev (unless those partitions were changed to allow the user access to them, which usually doesn't make sense). – CrazyCasta Feb 17 '13 at 01:27
  • P.S. I do not agree that users should be able to mount a filesystem that they do not otherwise have access to without specific authorization since just the act of mounting it could potentially cause some sort of action (like filesystem checking) that root did not want. – CrazyCasta Feb 17 '13 at 01:36
  • Mounting an image still involves device nodes (eg, /dev/loop). You are right that this creates a hassle, but "making arrangements" for that is going to vary from system to system (there is finite supply of loop devices, for one thing), so again, that's why by default it is all restricted. But that default can still be overridden, by the super user, on behalf of whoever else. – goldilocks Feb 17 '13 at 01:36
  • That's a good point about the limit of loop-back device nodes.

    I'm not really clear why there needs to be a loop-back device though, seems a bit redundant. I know it's because mounting requires a block-wise file rather then a normal file. I don't understand why this is though. Can you offer any insight, like does the kernel treat block devices and regular files significantly differently?

     – CrazyCasta Feb 17 '13 at 01:50
  • I would guess because loopback devices are supposed to be devices. Ie, that would be a feature and not a flaw, even if having it simulate a device has a drawback in some context. After all, you don't have to mount an image, you could extract and re-write it. – goldilocks Feb 17 '13 at 03:22
  • This answer is bollocks. While it's true that direct access to hardware is something that a non-kernel-space process should never be able to do, at least by default, it's not true that adding a remote folder that the user already has access to is something that non-root should not be able to do, nor is it something that cannot actually be done (see FUSE). Also, device files is a user-space concept, it does not receive or send interrupts directly; interrupts always causes context switch to the kernel and can only be received in the kernel-space. – Lie Ryan Feb 17 '13 at 12:34
  • @Lie Ryan That device nodes exist in user space is obvious, that devices are a purely user space concept is FALSE; the kernel even uses the major/minor numbers which are the essence of the node files. That they "do not send interrupts directly" is sort of non-sensical; they certainly are a link in a (the) chain that involves interrupts. I agree that the OP should be allowed to mount a remote folder at his lab, but I disagree that anyone should just be allowed to do so by default. If they were, admins could just do the opposite and the guy would still be in the same boat. Who won? – goldilocks Feb 17 '13 at 13:33
  • @goldilocks: if you can receive interrupt directly by reading device files is the reason why you need root privilege for mount, then you should not be able to do any kind of file read/writes without root privilege, since they also always creates interrupts. Device drivers are the part of the kernel that sits between the hardware and device files, interrupts causes a context switch to the device driver which is part of the kernel and runs in kernel space, they're not sent directly to the device files. Virtual filesystems does not need to be a device driver, it does not need to run in Ring 0. – Lie Ryan Feb 17 '13 at 13:49
  • @Lie Ryan:The difference is that the sys admin can control what hardware is in use, as opposed to letting just anyone do it. WRT Virtual filesystems, again, I agree, you should and could be allowed. Just not as an irrevocable right (also, see my earlier comment vis, how the loopback is suppose to be a device, and you can access images without mounting them, so..) I substantially re-wrote this partially thanks to your "bollocks" comment, lol. It was disorganized. I put some more stuff in about the interrupt issue if you are interested. I know you don't like it, but that is what a device is. – goldilocks Feb 17 '13 at 14:26
  • 1
    @goldilocks: The reason this answer is bollocks is because your theory behind the restriction is very convincing, but it is totally wrong, the issue you referred to does not exist. Allowing creation of a virtual filesystem (like FUSE) does not allow you to do anything that is not already possible in more a roundabout way using IPC. Your note regarding interrupts on devices is totally irrelevant; the only significant interrupt that is happening on for remote filesystem comes from the network card, which are handled wholly by the kernel. – Lie Ryan Feb 17 '13 at 15:31
  • @goldilocks: if devices are problematic because they are external, independent entities, that they are physical things that the kernel cannot completely control, then web browsers would have been impossible, because web servers are external, independent entities which the kernel has no control at all, it would not have been possible for sockets to do "server-initiated push" and it would not have been possible for a server to receive "client-initiated request" because the server's kernel does not have control over the client machines. – Lie Ryan Feb 17 '13 at 15:39
  • I agree (again -- this is the same thing over and over) that the interrupt issue WRT virtual and remote filesystems is just theoretical. There are software solutions to this (as you mention, FUSE), so big deal. The real issue is the policy at the OP's lab. WRT to web servers -- they do not exist for the kernel at all. What exists is a network device, and that is an external entity with which the kernel interfaces directly and delivers packets applications. Push-pull etc. is all user space. This context should have been obvious. :/ – goldilocks Feb 17 '13 at 15:42
  • For more understanding of issues other than interrupts and kernel performance -- that is, security issues -- see Gilles answer. Unlike interrupts, these apply equally to virtual and remote filesystems. – goldilocks Feb 17 '13 at 15:48
  • @goldilocks: Accessing a virtual filesytem does not cause hardware interrupt, only a software interrupt to context switch between the filesystem daemon and the program that uses the filesystem; in this manner, virtual filesystem is more similar to IPC than to device drivers. Filesystem is a concept that only exists in software, it does not need to involve hardware interrupt at all. Also, you misunderstood Mauerer; it is not disabling interrupts that are detrimental to performance, it is the alternative strategy, polling, have to run in real time, which causes interrupt to be more performant. – Lie Ryan Feb 17 '13 at 15:51
  • If it will make you any happier, I'll add a more explicit caveat about virtual filesystems. I do not misunderstand Mauerer and I did not say the performance issue was about disabling interrupts, I said it was about interrupts period. The fewer sources of such, the better, which is one reason not to allow umpteen people to attach hard drives. – goldilocks Feb 17 '13 at 15:59
  • This description of interrupts is wildly wrong. The kernel is in complete control of them. It chooses to enable them because it expects the device to signal when it has completed the IO request that the kernel asked it to do, and only the kernel can submit those requests. If it detects a device is interrupting excessively/needlessly, then it will disable the interrupt. A process can try to generate a lot of IO to bog down the system no matter who mounted the filesystem, so the subject of interrupts is completely unrelated to mount permission. – psusi Feb 17 '13 at 18:04
  • @psusi This description of interrupts is not "wildly wrong" and the kernel cannot always disable them. The example of the defective hard drive demonstrates this case. If you do not believe me, google "linux uninterruptible sleep IO" and read away. With regard to processes being able to generate a lot of IO to bog the system down -- this is the same "problem" as a simple busy loop -- the primary issue with interrupts would be untrusted hardware. I will add a note qualifying my claims about multiple interfaces though, as that is a bit conjectural. – goldilocks Feb 17 '13 at 18:21
  • It can disable them, at least on any typical PC hardware with an 8250 PIC or APIC, and it will do so and log a message saying it did if it gets spurious interrupts. Uninterruptable sleep has nothing to do with interrupts or why mount is a privileged operation either. It is simply the state a process sleeps in while waiting for IO, during which time, signals are blocked simply because the kernel can't be bothered with the complexity of delivering a signal, and then returning to waiting for the IO. – psusi Feb 17 '13 at 19:32
  • You also seem to misunderstand the "interrupts issued as a result of hardware faults" bit. This has nothing to do with a disk having a bad sector. This refers to hardware traps for things like general protection faults ( SIGSEGV ). Bad sectors also have nothing to do with why mount is a privileged operation. When you hit a bad sector, the kernel simply tries to read it again, and if it still fails, reports the error to user mode. The unresponsiveness you typically get when this happens is due to the drive spending a long time trying to do its error correction, so no other IO can be done. – psusi Feb 17 '13 at 19:44
  • @psusi: Alright, you've made me rethink my take on the faulty hard drive; this won't cause such serious problems if it is not the system disk. I think the stuff about interrupts is still relevent, though, because it is still integral to what a device is to the kernel, and as such a concern WRT letting untrusted users plug in hardware. The whole discussion is ridiculous, since the original dilemma behind it could be easily dealt with without the boy who cried wolf re-designing linux. I'll think about taking this down as having gone off the rails into besides the point land. All apologies :( – goldilocks Feb 17 '13 at 19:52
  • The reason it's irrelevant is because how some devices work has nothing to do with why users normally aren't given access to them, and more importantly for the purposes of this question, why users can't mount a filesystem on them even if they are given access to the device. – psusi Feb 19 '13 at 15:49
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.

Paulo Tomé
  • 3,782
BraveNewCurrency
  • 151
  • 2
  • Namespaces are more limited than that. You can appear root inside a user namespace, but it does not let you mount normal filesystem types even if you can read & write the block device. See experiment 2 here: https://unix.stackexchange.com/questions/517317/about-mounting-and-umounting-inherited-mounts-inside-a-newly-created-mount-names/517360#517360 – sourcejedi May 20 '19 at 15:19
0

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).

sendmoreinfo
  • 2,573
  • Could you elaborate? I'm not sure how "the data on filesystem they intend to mount" would compromise security. If you can read/write the file normally then you should be able to mount it (is my argument). If I can read/write a mount point then I should be able to everything mount can with the exception of actually mounting it to a directory. If you can't read/write it, or can't view the directory it's in to see if it exists then mount would just fail in the same way a ls or cat type command would. –  Feb 17 '13 at 00:45
  • Your argument is valid if 'you' are the single user; remember that Linux (and Unix) are multi-user systems, where users are not necessarily trusted. – sendmoreinfo Feb 17 '13 at 00:54
  • suid binaries could be added to a device, mounted on your box and used to root a box, which is why by default owner and user(s) set nosuid. You wouldn't want someone being able to bypass that easily with allowing them to manually remove the nosuid – R. S. Feb 17 '13 at 01:05
  • @sendmoreinfo I'm well aware that Linux is a multi-user system, there's no need to be patronizing. I am wondering why I am restricted from mounting network shares and image files that I otherwise have plenty of access. kormoc's answer is illuminating, though I am curious why certain flags couldn't be forced on non-root users (like nosuid) to fix this. It seems like I should be able to mount for the purpose of simple read/write an image file/network share that I otherwise have access to onto a mount point that I own. – CrazyCasta Feb 17 '13 at 01:23
  • 1
    @CrazyCasta WRT "making the system crash", it is certainly possible to mount defective hardware which exploits vulnerabilities in the hardware interface. Anyone who's had a hard drive with enough bad blocks on it can tell you how it can affect the kernel (and hence the whole system) -- it goes into a busy loop and effectively paralyses the whole kit and kaboodle. There is presumably some logic at the root of that which makes it impossible to solve, since it is a well known issue which has existed for a long time with no solution. – goldilocks Feb 17 '13 at 01:48
  • @goldilocks That's a very interesting issue that I wasn't aware of. I'm glad I haven't any drives go south like that. However, I would argue that that should fit under the user doesn't have access to the device itself category, since it would seem that the same issue could be triggered by simply reading from the block device (i.e. dd if=/dev/sda of=/dev/null). – CrazyCasta Feb 17 '13 at 01:52
  • it's more just likely that no one has decided to take the time or was paid to take the time to write the code to do it securely. There's honestly likely no unsurmountable technical reason why it couldn't be done with enough restrictions. – R. S. Feb 17 '13 at 01:54
  • The user not having access to the device node covers the whole issue, because you can't mount anything without a device node (whether it represents a real physical device or not). They are not real files, btw, they are representations used as an interface with the kernel; I think you are a little confused by that? – goldilocks Feb 17 '13 at 01:58
  • I understand they aren't files on some filesystem somewhere, but I would disagree with your characterization of what a file is. In Unix and by extension Linux, basically everything is a file. There's some weirdness about sockets because they aren't in the filesystem, but every other way that you interact with the kernel is represented in some fashion by a file. Therefore, I would call the device nodes files. – CrazyCasta Feb 17 '13 at 02:07
  • Yeah, I agree with that, I was trying to make a distinction I think you understand already, vis, device nodes are special (but really files are special in unix, as you say, and device nodes are "special files"). All apologies. – goldilocks Feb 17 '13 at 03:40
0

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.

Lie Ryan
  • 1,228