What is this restriction for in terms of safety? And when connecting external drives via USB, the root password is not required. I can't understand the logic.

I use the following rule in the fstab to connect the internal drive at runtime:

LABEL=disk /media/user/disk ext4 rw,nosuid,nodev,noexec,discard,relatime,user

How would such a rule add vulnerability?

  • 4
    It's the same for internal and external disks. The difference is that using mount requires root, whereas udisks does not
    – user163495
    Jan 9, 2022 at 14:22
  • @MechMK1 In Debian the external USB HDD is mounted without a password request, but the internal one, when I connect it to the work computer, asks for the root password
    – NewLinux
    Jan 9, 2022 at 14:46
  • Linux normally does not distinguish between internal SCSI and external USB devices. Maybe the LABEL=disk does not work for the internal disk. Have you tried /dev/sdaX (or /dev/hdaX) instead of LABEL=disk? I doubt that the difference is an intended behavior. Jan 10, 2022 at 7:45
  • @MartinRosenau Without fstab at all: external USB is mounted, but removable SATA SSD is not. By connecting this SATA SSD through a USB adapter - everything works.
    – NewLinux
    Jan 10, 2022 at 12:15
  • 1
    Obligatory xkcd
    – AndreKR
    Jan 11, 2022 at 14:46

5 Answers 5


Mounting filesystems has multiple very high security risks, and should not be taken lightly.

Having said that, there are multiple tools (like udisks and the user option in fstab) that run with elevated privileges and try to mitigate risks while allowing users to mount disks. Most of the mitigations work by carefully controlling mount options.

Here is a short (and incomplete) list of possible risks:

  • a maliciously malformed filesystem could cause the system to crash or trigger buffer overrun errors in the kernel (mitigation: run filesystem check first and reject or repair malformed filesystems)
  • a maliciously populated filesystem could include setuid binaries or devices with open permissions that would allow privilege escalation (mitigation: mount with nosuid,nodev and possibly noexec)
  • mount options can allow mounting of existing partitions while forcing file ownership changes via mount options (mitigation: restrict users from supplying mount options)
  • mount can replace existing system directories (mitigation: only allow user triggered mounts on special designated directories)
  • unmounting arbitrary filesystems could cause a denial of service attack (mitigation: only allow user mounted filesystems to be user unmounted)

To summarize, mount is a system critical function and its effects can severely impact system integrity and security, so it should only be allowed by non-admin users in extremely restricted conditions.

  • Thanks for the detailed answer, mounting is really akin to granting root access (tried it as an experiment). And what can you say about my fstab rule, how can it be dangerous?
    – NewLinux
    Jan 9, 2022 at 15:22
  • 4
    Assuming this is an internal disk, it is unlikely to have malicious modifications made to it, and just by having it in fstab you are restricting mount options, so it's probably fine. You already have two of the mitigations in place.
    – user10489
    Jan 9, 2022 at 15:25
  • There wasn't always a check for mounting the same device twice. Cue corrupt kernel memory.
    – Joshua
    Jan 10, 2022 at 3:01
  • @user10489 Having it in /etc/fstab does not actually restrict mount options on Linux, just specifying both device and mount point when mounting causes options in /etc/fstab to be ignored by default with the version of mount provided by util-inux (and it also has options to ignore the options in /etc/fstab even if you just specify device or mount point). Jan 10, 2022 at 13:43
  • 2
    Yes, @AustinHemmelgarn, but mounting that way requires privilege. So although it is true that fstab entries do not limit the possible mount options for filesystems, they do not only limit but explicitly specify the mount options that apply to unprivileged mounting enabled by the appearance of the user option in such an entry. Jan 10, 2022 at 17:32

On most modern Linux distributions, there is a helper called udisks that allows users to mount removable drives, such as USB drives, so that they don't have to have root privileges. However, this helper doesn't typically run on non-removable disks, so it won't apply to internal drives.

The main reason that mounting a disk requires privileges is because it introduces the kernel to untrusted data, which is risky. The file system could be malicious or malformed, such as by having self-referential data structures, and this could lead an unprivileged user to cause a DoS or arbitrary code execution. Various other reasons are possible as well, as outlined by user10489.

More importantly, the same privileges are required for both mounting and unmounting, and generally the reason that udisks only works on removable drives is that allowing the user logged into a machine at the console to unmount an internal disk could cause the system to stop working. For example, if I had a restricted kiosk or business center computer and could unmount the root file system, I could take the kiosk out of service for everyone else until someone came to reboot it. This is the reason that unmounting drives typically requires privileges, since Unix systems are designed for multple users.

  • You'd have a really hard time unmounting the root filesystem, though, even as root. Or any filesystem that was in use (with open files).
    – ilkkachu
    Jan 9, 2022 at 23:35
  • 4
    I wouldn't say malicious filesystems are the "main" reason. More like the main reason is that if you can run arbitrary mount commands, you can replace any file or directory on the system. Basically, if you can run mount without restriction, you have root access, even without exploiting bugs in the kernel or introducing strange data structures.
    – user10489
    Jan 9, 2022 at 23:59
  • @user10489 However you have put "malicious filesystems" as the first point in your list, which is surprising. The only scenario I can think about is when I want to get access to e.g. John's computer by using some flaw in kernel module so I give John a specially "cooked" USB stick. In other cases when I can inject such stick myself, I don't need to do any voodoo as I have a physical access to the computer thus I can access the data directly.
    – dma_k
    Jan 21, 2022 at 9:09
  • Malicious filesystems are the hardest thing to check for, but not the most dangerous thing you can do with mount.
    – user10489
    Jan 21, 2022 at 12:28

It's hard to tell why the system asks you for a password, without knowing the command you're running. fstab certanly can't ask you for a password, as it is not an executable file.

As you have user specified for /media/user/disk, running mount /media/user/disk as a regular should not ask for a password. In fact, mount never asks for a password at all, it either succeeds or fails. You're probably running sudo mount /media/user/disk, and sudo asks you for a password anyway, because it has no way of knowing the command you're about to run doesn't need to be executed as root

Also note that noexec, nosuid, and nodev parameters are implied when user is specified, so they have no effect.


What is this restriction for in terms of safety? And when connecting external drives via USB, the root password is not required. I can't understand the logic.

Unix-like systems were designed as multi-user systems and mounting of drives was/is considered an administrative action. A disk may contain data that some users are not allowed to access, it may contain setuid binaries that create a security risk.

As desktop (and even more so laptop) systems that are typically used by a single user at a time became more common, mechanisms were devised to grant the user who is logged into the computer locally some permissions that would normally be reserved to the system administrator. There have been several generations of such systems over the years, as far as I can tell Debian currently use policykit for this purpose.

Most Linux distributions with desktops default to granting users who are logged in locally permission to mount "removable" media. The logic is presumably that removable disks are under the control of the person sitting at the computer and they wouldn't be very useful if every time someone wanted to insert or eject a disk they had to call a sysadmin over. The security vulnerabilities of mounting are mitigated to some extent by restricting the mount location and mount options.

When USB drives came along, they got grouped with removable media from the perspective of the default policy, presumably because that is how in-practice most users use them.

If you are running a high-security shop you will probably want to review the default policies. Default policies in an OS distribution will always be a compromise between security and usability. Mounting a potentially malicious drive even with restricted mount options does bring some risks.

Internal drives on the other hand are still considered the domain of the system administrator and may contain stuff the user currently sitting at the computer is not supposed to access.


Originally, only root could do any mounting.

One reason for this is that arbitrary mounting allows you to mount something over /etc which contains a passwd (and shadow for systems which have it) with contents you control, so you can then log in as any user including root. This is why when user mounts were added they were restricted to specific, safe locations, either by specifying fixed posibilities in /etc/fstab or via tools which only mount in places reserved for them (e.g. pmount). In addition to the obvious problem with replacing /etc, in principle any directory might be security critical depending on what software is being used, so it's not sufficient to block access to a fixed list of dangerous places.

Another way to get root access if you can mount is to mount a filesystem which has a set-uid executable in it. This is why user mounts must always disable setuid for anything they mount. When a volume is mentioned in fstab setuid can be left enabled because the volume has been specifically permitted by the administrator so should be as safe as any other part of the filesystem.

And thirdly, if there is a volume which is normally mounted at a specific place (e.g. /home/alice/secretproject/bigdata) then it may contain data which is normally protected by the permission on a higher directory (in this case, presumably, /home/alice/secretproject). If you could mount it elsewhere, then you could gain access you shouldn't have (this could be mitigated by alice setting the permissions for all files in the root of the volume, but that is weak as it also requires remembering to do it when new files are added). When user mounts are permitted, this weakness is avoided in two different ways. For internal volumes, you can only mount them via fstab, so the administrator has deliberately made them available at fixed places. For external drives, the fact that you have physical posession of the device means you could put it in any machine you control, so by letting you mount it you are not being given any access you don't already have. This is why the default does not allow the same for internal drives. You might be accessing the system remotely with the volume inside the computer securely locked away in a room you don't have access to, so allowing you to mount the volume gives you access you wouldn't otherwise have.

I note that other answers mention malformed filesystem. This is clearly nonsense as external USB drives could just as easily be malformed and since they are under the control of the person inserting them could be used as an attack if malformed filesystems cause a problem. In contrast, an internal device could have been vetted by the administrator so potential malformation is not a reason to prohibit users mounting it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .