Hide Forgot
## Ancillary info $ head -n1 /etc/issue Red Hat Enterprise Linux Workstation release 6.2 (Santiago) $ rpm -q libguestfs libguestfs-1.7.17-26.el6.x86_64 $ getenforce Permissive $ id uid=162(nova) gid=162(nova) groups=162(nova),99(nobody),107(qemu),493(fuse) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ls -lad /tmp/tmpXR3TxB/ /tmp/disk -rw-r--r--. 1 nova nova 23068672 Dec 9 14:00 /tmp/disk drwx------. 2 nova nova 4096 Dec 9 13:06 /tmp/tmpXR3TxB/ ## Now mount the image as the nova user # runuser -s /bin/bash nova $ guestmount --rw -a /tmp/disk -m /dev/sda /tmp/tmpXR3TxB/ ## That worked and we can create files in the /root directory therein $ ls -lad /tmp/tmpXR3TxB/root drwx------. 3 root root 1024 Dec 9 13:45 /tmp/tmpXR3TxB/root $ touch /tmp/tmpXR3TxB/root/a ## However we can't chdir? Is this a bug? $ cd /tmp/tmpXR3TxB/root bash: cd: /tmp/tmpXR3TxB/root: Permission denied ## Anyway the above is compounded by the fact that the root user ## can't access the user mounted fuse file system at all # ls -lad /tmp/tmpXR3TxB/ ls: cannot access /tmp/tmpXR3TxB/: Permission denied Perhaps a fuse issue? Anyway for the moment for me it mandates I run guestmount as root
FUSE doesn't let users see each other's mounts, unless you change some options. See: http://libguestfs.org/guestmount.1.html#other_users_cannot_see_the_filesystem_by_default http://sourceforge.net/apps/mediawiki/fuse/index.php?title=Fuse.conf and the output of guestmount --fuse-help
OK trying that gives a further 2 issues: $ guestmount --rw -o allow_root -a /tmp/disk -m /dev/sda /tmp/bb fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf $ echo $? 0 First is that EXIT_SUCCESS is returned for this failure to mount. Richard has fixed that bug already in libguestfs :) So I'm not logging separately. The second is that I'd need to do this in my packaging: echo user_allow_other >> /etc/fuse.conf I'm not sure if we could safely remove on package removal. I guess we could tag it with a comment if the file supports comments. The bigger security issue though, is that it might expose the root user to arbitrary setuid files etc. So I'm thinking it might be best to keep running guestmount as root, as we need to access the mounted image as root anyway due to the "cd issue" mentioned in comment #1
The EXIT_SUCCESS issue was fixed in libguestfs-1.14.7-1 The root access restriction is by design, so closing...