How to allow non-superusers to mount any filesystem?

Question

Is it possible to allow some particular users (e.g. members of a group) to mount any filesystem without superuser privileges on Linux?

Another question might have been "in what ways a user can harm a system by mounting filesystems?"

Answer 1

There are a couple approaches, some of them mostly secure, others not at all.

The insecure way

Let any use run mount, e.g., through sudo. You might as well give them root; it's the same thing. The user could mount a filesystem with a suid root copy of bash—running that instantly gives root (likely without any logging, beyond the fact that mount was run).

Alternatively, a user could mount his own filesystem on top of /etc, containing his/her own copy of /etc/shadow or /etc/sudoers, then obtain root with either su or sudo. Or possibly bind-mount (mount --bind) over one of those two files. Or a new file into /etc/sudoers.d.

Similar attacks could be pulled off over /etc/pam.d and many other places.

Remember that filesystems need not even be on a device, -o loop will mount a file which is owned (and thus modifiable) by the user.

The mostly secure way: udisks or similar

The various desktop environments have actually already built solutions to this, to allow users to mount removable media. They work by mounting in a subdirectory of /media only and by turning off set-user/group-id support via kernel options. Options here include udisks, udisks2, pmount, usbmount,

If you must, you could write your own script to do something similar, and invoke it through sudo—but you have to be really careful writing this script to not leave root exploits. If you don't want your users to have to remember sudo, you can do something like this in a script:

#!/bin/bash
if [ $UID -ne 0 ]; then       # or `id -u`
    exec sudo -- "$0" "$@"
fi

# rest of script goes here 

The will-be-secure someday way: user namespaces

Linux namespaces are a very lightweight form of virtualization (containers, to be more specific). In particular, with user namespaces, any user on the system can create their own environment in which they are root. This would allow them to mount filesystems, except that has been explicitly blocked except for a few virtual filesystems. Eventually, FUSE filesystems will probably be allowed, but the most recent patches I could find don't cover block devices, only things like sshfs.

Further, many distro kernels have (for security reasons) defaulted to not allowing unprivileged users to use user namespaces; for example Debian has a kernel.unprivileged_userns_clone that defaults to 0. Other distros have similar settings, though often with slightly different names.

The best documentation I know of about user namespaces is an LWN article Namespaces in operation, part 5: User namespaces.

For now, I'd go with udisks2.

Answer 2

You can do it, but you need to modify the entry in /etc/fstab corresponding to the filesystem you want to mount, adding the flag user to this entry. Non-privilege users would then be able to mount it.

See man mount for more details.

Answer 3

Here is the wiki for configuring polkit rules for udisks/udisks2 in order to mount partitions by non-root (e.g. users) group.

Save the code below to /etc/polkit-1/rules.d/50-udisks.rules

polkit.addRule(function(action, subject) {
  var YES = polkit.Result.YES;
  var permission = {
    // only required for udisks1:
    "org.freedesktop.udisks.filesystem-mount": YES,
    "org.freedesktop.udisks.filesystem-mount-system-internal": YES,
    "org.freedesktop.udisks.luks-unlock": YES,
    "org.freedesktop.udisks.drive-eject": YES,
    "org.freedesktop.udisks.drive-detach": YES,
    // only required for udisks2:
    "org.freedesktop.udisks2.filesystem-mount": YES,
    "org.freedesktop.udisks2.filesystem-mount-system": YES,
    "org.freedesktop.udisks2.encrypted-unlock": YES,
    "org.freedesktop.udisks2.eject-media": YES,
    "org.freedesktop.udisks2.power-off-drive": YES,
    // required for udisks2 if using udiskie from another seat (e.g. systemd):
    "org.freedesktop.udisks2.filesystem-mount-other-seat": YES,
    "org.freedesktop.udisks2.encrypted-unlock-other-seat": YES,
    "org.freedesktop.udisks2.eject-media-other-seat": YES,
    "org.freedesktop.udisks2.power-off-drive-other-seat": YES
  };
  if (subject.isInGroup("users")) {
    return permission[action.id];
  }
});

Assume you are in the "users" group, using the following command to mount a partition (no need sudo).

# udisks2
udisksctl mount --block-device /dev/sda1

# udisks
udisks --mount /dev/sda1

Answer 4

1 Look where it works

On Xubuntu it works out of the box to mount and eject USB mass storage, hard disk partitions, CD/DVDs and probably more.

Let's assume that the solution Ubuntu chose, using policyKit, is secure enough.

2 Pick the relevant part

On XFCE on Debian 8.3 I needed to allow user to mount and eject filesystems from thunar without password. What worked for me is to cherry-pick a permission file from Ubuntu.

Adding the lines below as root to a file named /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla should do the trick:

[Mounting, checking, etc. of internal drives]
Identity=unix-group:admin;unix-group:sudo
Action=org.freedesktop.udisks.filesystem-*;org.freedesktop.udisks.drive-ata-smart*;org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.encrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab;
ResultActive=yes

3 Profit!

(What I did actually was pick a little more from the file with same name on Ubuntu 16.04 and it worked for me. If you need it, it mostly looks like the content of https://gist.github.com/kafene/5b4aa4ebbd9229fa2e73 )

Answer 5

You can configure sudo to allow a set of users to run the mount command.

Update: as to how you can damage a system by mounting? For example, you can create a setuid root shell on a filesystem which you can then mount and execute to get root privileges.

Answer 6

guestmount libguestfs trickery

sudo apt-get install libguestfs-tools

# Workarounds for Ubuntu 18.04 bugs.
# https://serverfault.com/questions/246835/convert-directory-to-qemu-kvm-virtual-disk-image/916697#916697
sudo rm -rf /var/cache/.guestfs-*
echo dash | sudo tee /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/zz-dash-packages
sudo chmod +r /boot/vmlinuz-*

# Create a test image.
mkdir sysroot
dd if=/dev/urandom of=sysroot/myfile bs=1024 count=1024
virt-make-fs --format=raw --type=ext2 sysroot sysroot.ext2

# Mount it, have fun, unmount!
mkdir -p mnt
# /dev/sda becuase we have a raw filesystem.
guestmount -a sysroot.ext2.qcow2 -m /dev/sda mnt
cmp sysroot/myfile mnt/myfile
guestunmount mnt

Relies on:

• userland implementation of the filesystems
• FUSE

Docs: http://libguestfs.org/guestmount.1.html

Tested on Ubuntu 18.04, libguestfs-tools 1:1.36.13-1ubuntu3.

Answer 7

Simple secure way without sudo, acl, etc...

Look for to which group device file belongs to

ls -l /dev/sda2                                                                                                                                                                
brw-rw---- 1 root disk  /dev/sda2

Saw that device file belongs to group disk

Now add our user to group disk

usermod -G disk -a username

And now in /etc/fstab

/dev/sda2   /mnt/backups    ext4    noauto,group,suid,dev,async      0   2

or with UUID

UUID=c90324c1-3fba-119c-913c-5f913afdca8b   /mnt/backups    ext4    noauto,group,suid,dev,async      0   2

Now all users in group disk, for now it's only username, can mount certain disk.

Answer 8

I'am on ubuntu 22.04

My root mount in fstab is like this: UUID=myuuid / ext4 errors=remount-ro,user=owner 0 1

So, i dont have a owner user into passwd conf file, but i think this owner is the absolute owner of the mount point (directory) ... / has root owner /home/whateveruser has whateveruser owner /media/myuser/mypendrive has myuser owner

We dont need to specify user=listofusers. Owner is sufficient to get root and effective logged user(s)

My usb 3.0 pendrive is getting almost 200 MB transfer rate, after i set user=owner at / ext4 mount point.

I dont know if that works like i said, but i can boot with no mount errors nor systemd errors ;)

Answer 9

Maybe we could use this options:

user=owner (root, disk, whatever directory owner) and/or group=owner (root, disk, whatever directory owner)

owner is whatever authenticated user from group(x)

we know / is owned by root /home/myuser us owned by myuser etc ...

Mounting respecting individual directory permissions match

Answer 10

To answer your question in parenthesis, since a filesystem is a placeholder for files, then a user can potentially carry out harmful operations on that filesystem, such as delete files.

Summarising the other 2 questions I will say this:

• fstab is great for mounting at boot time permanent storage. It is not so great when you want to plug in usb drives or mount occasionally some network shares.

• sudo mount is also alright if you are on ubuntu* systems. You will still need to type in a password though.

• udev will take care of mounting things like usb sticks, cameras and flash cards in ubuntu* systems (but not in less user friendly distros like debian, slackware, etc)

I'll add that, historically, the unix way to give authority to some users (or groups) to do stuff is through the sudoers file.

There are MANY guides to use it out there so I will not suggest any particular. I will say that I used the Linux documentation project website to learn about it.

What is more with sudoers is that you can mount devices and shares transparently - even without providing a password if you choose to do so (be extra careful about that).

What I usually do in a control environment is I use sudoers file to allow users of certain group to mount network shares transparently. So I add the commands mount.nfs and mount.cifs in the sudoers file that allowing operations such as "mount the home folder of user from a network file server, when the user logs on to a client terminal" and studd like that.