Description of problem: When mounting a vmdk image with guestmount, if the folders inside the image has 0700 permissions for a non-root user, root is unable to access them How reproducible: [root@example adm]# df -h . Filesystem Size Used Avail Use% Mounted on guestmount 992M 40M 902M 5% /mnt/vmdk [root@example adm]# pwd /mnt/vmdk/home/adm [root@example adm]# mount | grep guestmount guestmount on /mnt/vmdk type fuse.guestmount (rw,nosuid,nodev) [root@example adm]# [root@example adm]# cd home/adm [root@example adm]# ls -l total 20 drwxr-xr-x 2 root adm 4096 Jul 11 2012 bin drwxr-x--- 2 root adm 4096 Jul 11 2012 etc drwx------ 2 hpsupp adm 4096 Jul 11 2012 hpsupp drwxr-xr-x 2 root adm 4096 Feb 4 2009 man -r--r----- 1 root adm 424 Jul 11 2012 profile [root@example adm]# cd hpsupp -bash: cd: hpsupp: Permission denied [root@example adm]# id uid=0(root) gid=0(root) groups=0(root),4(adm) [root@example adm]# Reading the directory through tar works: [root@example adm]# pwd /mnt/vmdk/home/adm [root@example adm]# tar cfv /tmp/hpsupp.tar hpsupp/ hpsupp/ hpsupp/.bash_profile [root@example adm]# cd /tmp [root@example tmp]# tar xfv hpsupp.tar hpsupp/ hpsupp/.bash_profile [root@example tmp]# head -2 hpsupp/. ./ ../ .bash_profile [root@example tmp]# head -2 hpsupp/.bash_profile # .bash_profile [root@example tmp]# Actual results: Access not allowed to root Expected results: Root should have access as if it were on a normal mountpoint Additional info:
Reproducer (on Fedora Rawhide): cd /tmp guestfish -N fs -m /dev/sda1 mkdir /foo : touch /foo/bar : chmod 0700 /foo mkdir /tmp/mnt guestmount -a test1.img -m /dev/sda1 /tmp/mnt This works: $ cd /tmp/mnt This does not work: $ cd /tmp/mnt/foo bash: cd: /tmp/mnt/foo: Permission denied This works: $ ls -al /tmp/mnt/foo total 2 drwx------. 2 root root 1024 Jun 12 11:51 . drwxr-xr-x. 4 root root 1024 Jun 12 11:51 .. -rw-r--r--. 1 root root 0 Jun 12 11:51 bar
Actually the reproducer in comment 2 is wrong, although it does reveal a different-but-related bug. > This does not work: > > $ cd /tmp/mnt/foo > bash: cd: /tmp/mnt/foo: Permission denied It's good that this doesn't work! A root-owned drwx------ directory should not be enterable or readable by an ordinary user. > This works: > > $ ls -al /tmp/mnt/foo > total 2 > drwx------. 2 root root 1024 Jun 12 11:51 . > drwxr-xr-x. 4 root root 1024 Jun 12 11:51 .. > -rw-r--r--. 1 root root 0 Jun 12 11:51 bar This is a bug! The directory should not be readable by the non-root user.
Let's try a different reproducer which is more similar to the original problem ... Run the following commands *as root*: cd /tmp mkdir /tmp/mnt guestfish -N fs -m /dev/sda1 <<EOF mkdir /foo touch /foo/bar chmod 0700 /foo chown 1 1 /foo EOF guestmount -a test1.img -m /dev/sda1 /tmp/mnt Run the following test *as root*: # cd /tmp/mnt/foo bash: cd: /tmp/mnt/foo: Permission denied # ls -al /tmp/mnt/foo total 2 drwx------. 2 bin bin 1024 Jun 12 13:16 . drwxr-xr-x. 4 root root 1024 Jun 12 13:16 .. -rw-r--r--. 1 root root 0 Jun 12 13:16 bar Because we are running as root, we would NOT expect that permissions are honoured, since normally root causes file permissions to be ignored. In other words, the 'cd' command should NOT fail. We can compare this situation to a regular (non-FUSE) directory which is owned by bin:bin: root@choo:/tmp/p# cd foo2 root@choo:/tmp/p/foo2# ls -al total 8 drwx------. 2 bin bin 4096 Jun 12 11:58 . drwxrwxr-x. 3 rjones rjones 4096 Jun 12 11:58 .. -rw-rw-r--. 1 rjones rjones 0 Jun 12 11:58 bar
Patch posted upstream: https://www.redhat.com/archives/libguestfs/2014-June/msg00053.html
Patch is upstream, but waiting for QA ack.
9b5cdc874784437d7a59bd024043c2abd930b6c3 is the upstream commit fixing this bug, part of libguestfs >= 1.27.16.
Reproduced on libguestfs-1.20.11-2.el6.x86_64 Verified on libguestfs-1.20.11-10.el6.x86_64 # cd /tmp # mkdir /tmp/mnt # guestfish -N fs -m /dev/sda1 <<EOF > mkdir /foo > touch /foo/bar > chmod 0700 /foo > chown 1 1 /foo > EOF # guestmount -a test1.img -m /dev/sda1 /tmp/mnt # cd /tmp/mnt/foo # ls -al /tmp/mnt/foo total 2 drwx------. 2 bin bin 1024 Sep 3 01:05 . drwxr-xr-x. 4 root root 1024 Sep 3 01:05 .. -rw-r--r--. 1 root root 0 Sep 3 01:05 bar
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1458.html