Can I mount a file system image without root permission? Normally I would do:
mount -o loop DISK_IMAGE FOLDER
Without using sudo or setting the suid on mount, is there any suitable way to do this?
I know I can use fusermount with some ISO images, but that is pretty limited, even for ISO images, some of my images cannot be mounted, but mount always works.
You can't mount anything that the administrator hasn't somehow given you permission to mount. Only root can call the mount system call. The reason for this is that there are many ways to escalate privileges through mounting, such as mounting something over a system location, making files appear to belong to another user and exploiting a program that relies on file ownership, creating setuid files, or exploiting bugs in filesystem drivers.
The mount command is setuid root. But if you aren't root, it only lets you mount things that are mentioned in fstab.
The fusermount command is setuid root. It only lets you mount things through a FUSE driver, and restricts your abilities to provide files with arbitrary ownership or permissions that way (under most setups, all files on a FUSE mount belong to you).
Your best bet is to find a FUSE filesystem that's capable of reading your disk image. For ISO 9660 images, try both fuseiso and UMfuse's ISO 9660 support (available under Debian as the fuseiso9660 package).
sudo (although it has the SUID bit set) only allows one to mount fstab entries. From this it follows that (a) the SUID bit makes sense, as a regular user can mount fstab entries (and is allowed to perform the mount syscall) and (b) that it is the mount utility's restriction to only allow fstab entries to be mounted by non-root users.
– David
Feb 03 '16 at 09:30
fstab are for the rootfs and boot. To mount USB drives I look at lsblk and mount accordingly. I have not had problems doing this.
– sherrellbc
Aug 05 '16 at 15:56
The Debian Wiki shows several ways of doing this. Here's one way. This requires the udisks2 package to be installed.
First, create a 'loop device.' This will allow us to mount the image file.
$ udisksctl loop-setup -f $PATH_TO_IMAGE
Mapped file $PATH_TO_IMAGE as /dev/loop0.
Notice that it mapped the image at /dev/loop0. However, if the previous command had returned /dev/loop1, then you would replace /dev/loop0 with /dev/loop1 in all of the following commands.
You might need to run this command if the block device we created is not automatically mounted with the previous command:
$ udisksctl mount -b /dev/loop0
Mounted /dev/loop0 at /media/$USER/$IMAGE_NAME
You can look at files on the disk:
$ ls -l /media/$USER/$IMAGE_NAME/
You can unmount it when you're done:
$ udisksctl unmount -b /dev/loop0
$ udisksctl loop-delete -b /dev/loop0
sudo only. setsid or related shenanigans?
– Ciro Santilli OurBigBook.com
Oct 10 '18 at 14:07
udisksctl loop-setup required sys admin authentication for me on RHEL7. Don't know if that is the default config for RHEL, or my organization's hardening.
– pavon
Aug 09 '21 at 23:24
You can use the FUSE module guestmount to mount several types of disk images. It's part of the guestfs ecosystem and won't require root permissions.
Take a look at the man page for further details.
1. For a typical Windows guest which has its main filesystem on the first partition:
guestmount -a windows.img -m /dev/sda1 --ro /mnt
2. For a typical Linux guest which has a /boot filesystem on the first partition and the root filesystem on a logical volume:
guestmount -a linux.img -m /dev/VG/LV -m /dev/sda1:/boot --ro /mnt
The way possible would be to add an /etc/fstab entry for the ISO with the 'user' parameter, like
/test.iso /mnt/iso auto defaults,user 0 1
But you usually need root access anyway to edit this file, so it's not very helpful.
It is actually very easy to mount more or less whatever you want as a
normal user without root privileges, provided the right entry has
been created in /etc/fstab.
Of course, modifications to /etc/fstab require root privileges. But
a single entry can
be used with much flexibility to (u)mount many different files on
different mount points, without any further editing of /etc/fstab.
Here are two very short (5 lines + comments) Bash scripts that will do the job:
for mounting
#!/bin/sh
# usage: usmount device dir
# author: babou 2013/05/17 on https://unix.stackexchange.com/questions/32008/mount-an-loop-file-without-root-permission/76002#76002
# Allows normal user to mount device $1 on mount point $2
# Use /etc/fstab entry :
# /tmp/UFS/drive /tmp/UFS/mountpoint auto users,noauto 0 0
# and directory /tmp/UFS/
# Both have to be created (as superuser for the /etc/fstab entry)
rm -f /tmp/UFS/drive /tmp/UFS/mountpoint
ln -s `realpath -s $1` /tmp/UFS/drive
ln -s `realpath -s $2` /tmp/UFS/mountpoint
mount /tmp/UFS/drive || mount /tmp/UFS/mountpoint
# The last statement should be a bit more subtle
# Trying both is generally not useful.
and for dismounting
#!/bin/sh
# usage: usumount device dir
# author: babou 2013/05/17 on https://unix.stackexchange.com/questions/32008/mount-an-loop-file-without-root-permission/76002#76002
# Allows normal user to umount device $1 from mount point $2
# Use /etc/fstab entry :
# /tmp/UFS/drive /tmp/UFS/mountpoint auto users,noauto 0 0
# and directory /tmp/UFS/
# Both have to be created (as superuser for the /etc/fstab entry)
rm -f /tmp/UFS/drive /tmp/UFS/mountpoint
ln -s `realpath -s $1` /tmp/UFS/drive
ln -s `realpath -s $2` /tmp/UFS/mountpoint
umount /tmp/UFS/drive || umount /tmp/UFS/mountpoint
# One of the two umounts may fail because it is ambiguous
# Actually both could fail, with careless mounting organization :-)
The directory /tmp/UFS/ is created to isolate the links and avoid clashes. But the symlinks can be anywhere in user space, as long as they stay in the same place
(same path). The /etc/fstab entry never changes either.
VITAL WARNING: Mounting is restricted for good security reasons. Making it more flexible may open doors for malicious software. I am not a security expert and I would recommend that you open doors no more than absolutely required ... using options to restrict what can be done with the file systems that can thus be mounted. If a knowledgeable contributor could comment further on security issues, it might be useful.
Various options are available to restrict the use of file systems that are mounted, such as noexec which prevents execution of
binaries, or nosuid, and thus contribute to security. Actually, these options are added as default options when the options user or users are used, which is necessarily the case in what we do below. Think twice before you override these defaults. http://en.wikipedia.org/wiki/Fstab
Other options can be added for further protection. For example, the option owner in the /etc/fstab entry will let users deal only with files or devices they own. See man mount for a list of options: http://linux.die.net/man/8/mount.
The use of this /etc/fstab entry can also be restricted through the user.group ownership of the directory (or directories) containing the symlinks.
Explanation
This explanation was written before I realised I could simplify things to the two scripts above. I did not think of them right away partly because I have at hand a slightly more complex problem that they do not solve without some extra machinery. Thus my explanation may be a bit more intricate than it should, but I do not have the courage to rewrite it all from scratch.
The basic idea is to create entries in /etc/fstab that include the
option user or users so that a user can ask mount to do the
mounting specified in that entry by giving as argument the file to be
mounted or the mount point to use (but not both in my expérience).
You also need a proper entry to umount (which is a slightly different problem - see below). The option user is usually better than users since it restricts permission to umount to the user who mounted the file system, while users will allow that to all. Unfortunately the option user does not always work, and may entail some other steps to be made to work. This is discussed in Option "user" work for mount, not for umount.
First you add to /etc/fstab an entry such as:
/tmp/UFS/drive /tmp/UFS/mountpoint auto users,noauto, 0 0
and use /tmp/UFS/drive as a symbolic link (or symlink) to whatever device or file
you wish to mount,
say a file containing the image of an ISO file system /home/johndoe/john-image-file.iso.
You also define /tmp/UFS/mountpoint as a symlink to the mount point you wish to use, say /mnt/iso.
You can then mount john-image-file.iso with the command :
$ mount /tmp/UFS/drive
This is sufficient on my Mageia Linux, since the use of loop devices
has now been made implicit, and no longer requires using -o loop explicitly. I do not know how general that is today. See
When mounting, when should I use a loop device?
This mounting appears in tables and commands :
$ df | tail -1
/dev/loop0 5,1G 5,1G 0 100% /mnt/iso
$ tail -1 /etc/mtab
/dev/loop0 /mnt/iso udf ro,nosuid,nodev,noexec,relatime,utf8 0 0
$ mount | tail -1
/home/johndoe/john-image-file.iso on /mnt/iso type udf (ro,nosuid,nodev,noexec,relatime,utf8)
$ tail -1 /proc/mounts
/dev/loop0 /mnt/iso udf ro,nosuid,nodev,noexec,relatime,utf8 0 0
$ tail -1 /proc/self/mountinfo
46 22 7:0 / /mnt/iso rw,nosuid,nodev,noexec,relatime - udf /dev/loop0 ro,utf8
$ tail -1 /proc/self/mountstats
device /dev/loop0 mounted on /mnt/iso with fstype udf
The mounting operation could work for any file or drive and requires only to
make a symbolic link from /tmp/UFS/drive to that file or to the device for the drive. Of course, another name and location could be chosen for the symbolic link, as long as it never changes.
Dismounting the file relies in the same way on appropriate use of symbolic links. In the case of a normal device corresponding to some harware drive, you just use the same links.
However, files containing the image of a file system are mounted via a special kind of device called a loop device, automatically allocated when you mount the file.
To dismount the file, you need to refer to the loop device, not the file.
Hence you need in /etc/fstab an entry that matches both the loop device
used in /etc/mtab, here /dev/loop0, and the mount point, here
/mnt/iso.
You cannot create such an entry in advance since the loop device may vary, as they are allocated dynamically. Note that it is also possible to use a fixed loop device, but it is inconvenient in other ways. See http://igurublog.wordpress.com/2011/01/22/how-to-allow-mounting-of-iso-files-by-a-regular-user/ (this blog actually inspired the reply here).
However, you can find the name of the loop device, here /dev/loop0, by asking the system, like we did above in several different ways. Then our standard /etc/fstab entry can be made to point to the right loop device via the symlink /tmp/UFS/drive, and to the mount point as done previously with /tmp/UFS/mountpoint. This done, the file may be dismounted with any of the following commands (provided there is no ambiguity with /etc/mtab, which is a different problem):
$ umount /tmp/UFS/drive
$ umount /dev/loop0
$ umount /mnt/iso
$ umount /tmp/UFS/mountpoint
Since the two symlinks are needed only when the commands are issued,
they can be changed dynamically. So our single /etc/fstab entry
allows mounting any number of files, and umounting them in any
order, without root privileges.
Other references:
mount command for every normal user?, and so the security issues associated with it? Correct me if I'm wrong.
– Bharat G
Oct 18 '15 at 04:20
device or the mountpoint section of fstab doesn't point to a valid entry. The user has to login via console session and enter startx to explicitly start a display manager.
– Bharat G
Oct 18 '15 at 04:49
Adding a note that this is completely possible to implement for a set of subprocesses, even if this has not been done yet.
A userspace mounter would emulate mounting using LD_PRELOAD or ptrace such as other utilities do to provide a fake root environment or transparent proxying. The child processes have their system calls routed to hooks that pretend to be the kernel in userspace.
Here's another question that itself links to more: https://superuser.com/questions/1601311/fuse-fs-without-root-privileges-e-g-a-ld-preload-gateway-or-a-proot-plugin
Package libguestfs-tools-c have guestmount command so
mkdir dvd
guestmount -a image.iso -r -i dvd
df will show image.iso mounted
df
to umount we have :
guestunmount dvd
UPDATE 2020.03.25 :
Package archivemount seems a cool tool
https://pkgs.org/download/archivemount
example:
archivemount zentyal-6.0-development-amd64.iso tmp3/
if non-root user starts GUI, GUI would auto mount USB device. Even I removed x permision of mount for non-root users.
mountbinary doesn't require SUID permissions then you should be able to use fakeroot without problems. – sakisk Feb 18 '12 at 15:31fakerootisn't going to help here: it pretends file ownership is different, but it can't give you permissions that you don't have, such as to callmount(2)when you aren't root. – Gilles 'SO- stop being evil' Feb 20 '12 at 02:55