44

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?"

40

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.

  • Thanks for your answer! BTW, would you reckon it is secure to allow users in the group mount to be able to mount filesystems like root does? I will read the namespaces document you've linked, and try to implement this mount group thing, at least as an exercise. – user27225 Oct 18 '13 at 16:16
  • @gkya I hope my first section has made it clear that allowing (a) mounting a filesystem without forcing nosuid [and also nodev]; or (b) at an arbitrary location is basically giving root. If you give someone permission to run arbitrary mount commands, that's the same as giving root. – derobert Oct 18 '13 at 16:19
  • @gkya from your "many removable drives with many partitions on each" comment on another answer, I'd guess you want the "udisks or similar" approach. – derobert Oct 18 '13 at 16:23
  • 1
    @derobert since you were talking about user namespaces, you may want to check out Plan 9 from Bell Labs (it's the successor to UNIX, made by the same people). it models the file tree as a per-process namespace (and there's no such thing as root). fascinating stuff. – strugee Oct 21 '13 at 4:11
  • 1
    @malan OK, I've updated it. If anything, I think using user namespaces for this looks to be even further into the future. – derobert Jan 4 at 19:08
13

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.

  • 1
    This is the only answer I can find with googling. I have found out that on FreeBSD, one can allow users to mount filesystems with setting a variable (namely vfs.usermount). I want sth. analogous to that. I use many removable drives with many partitions on each and it would be cumbersome to add a dozen or two entries to fstab for each of them. – user27225 Oct 18 '13 at 14:43
  • Ugly workaround could be to let udev manage the entries as new devices appear and disappear. – Jester Oct 18 '13 at 14:44
  • i have not found this to work on Mint or Ubuntu. Yes, the default user account can mount without root, but 'standard'/'desktop' users cannot mount it. – johny why Jun 8 '15 at 7:24
6

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
  • 2
    Seems like the way to go but did not work for me. – Stéphane Gourichon Mar 18 '16 at 17:16
3

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.

  • I have thought of this, but won't this require the user to run the command with sudo? Also, isn't it the root user mounting the file system, only behind the scenes, with this method? – user27225 Oct 18 '13 at 14:32
  • Yes, they would need sudo and yes it would run in the name of root. To solve the first issue, you could alias mount to sudo mount or use a wrapper script. – Jester Oct 18 '13 at 14:43
  • What I would like to have is to mount the filesystem without the agency of the root user. Masking this agency with anything is not what I'm after at all. – user27225 Oct 18 '13 at 14:48
  • Note that even adding user to fstab only works because mount is setuid root. The kernel is checking for root or CAP_SYS_ADMIN capability so you can't really get around involving root. – Jester Oct 18 '13 at 14:51
  • You can configure, how? This doesn't help. – Nuzzolilo Jan 1 '16 at 8:23
3

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 )

  • Only this works in debian like systems, don't know why putting rules on /etc/ didn't work. – Anwar Feb 10 at 5:33
  • Does not work on debian stretch. – Philipp Ludwig Apr 15 at 8:35
0

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.

  • 1
    If you're using sudo to let user's mount their home folders upon login, you should look at autofs. – derobert Oct 18 '13 at 16:11
  • I use these together; I could not figure out how to use autofs on its own to mount the /home/$USER from the fileserver, to the location /home/$USER/fromFS/ on the client pc. – nass Oct 18 '13 at 16:15
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy