Created attachment 802945 [details] screenshot from virt-install on F19 +++ This bug was initially created as a clone of Bug #702044 +++ Description of problem: When trying to attach iso from read-only filesystem (like NFS server administered by somebody else), it fails because iso's ownership cannot be changed to qemu:qemu Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. run VM with empty cdrom device 2. run 'virsh attach-disk win7x64 /path/on/readonly_fs/to/image.iso hdc --type cdrom; 3. Actual results: this error is throwed: error: Failed to attach disk error: unable to set user and group to '107:107' on '/mnt/trash/ic114/RHEV-toolsSetup_2.3_395.iso': Nepřípustný argument Expected results: disk is attached as read-only Additional info: * virt-manager fails with the same error * 107:107 are UID:GID in local system * unix permissions don't block qemu or libvirt from reading the isos, but selinux may block them (I don't know how to confirm this now) --- Additional comment from Laine Stump on 2011-06-02 16:28:56 EDT --- Nepřípustný argument == EINVAL The error comes (as you'd guess) from chown(2). But the manpage for chown doesn't mention the possibility of returning EINVAL. virSecurityDACSetOwnership already special cases EOPNOTSUPP, EPERM, and EROFS to ignore them. Would it be acceptable in all cases to just ignore EINVAL as well? --- Additional comment from Laine Stump on 2011-06-02 16:34:25 EDT --- --- Additional comment from Laine Stump on 2011-06-03 12:28:17 EDT --- The following fix has been pushed to upstream libvirt, and will be in the next rebase for RHEL6: commit 62ed801c13787cc844e75db7cd2d4c8a42454fcc Author: Laine Stump <laine> Date: Fri Jun 3 11:59:09 2011 -0400 security driver: ignore EINVAL when chowning an image file This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=702044 https://bugzilla.redhat.com/show_bug.cgi?id=709454 Both of these complain of a failure to use an image file that resides on a read-only NFS volume. The function in the DAC security driver that chowns image files to the qemu user:group before using them already has special cases to ignore failure of chown on read-only file systems, and in a few other cases, but it hadn't been checking for EINVAL, which is what is returned if the qemu user doesn't even exist on the NFS server. Since the explanation of EINVAL in the chown man page almost exactly matches the log message already present for the case of EOPNOTSUPP, I've just added EINVAL to that same conditional. --- Additional comment from Laine Stump on 2011-06-03 15:54:01 EDT --- The question in Comment 1 was already answered in IRC (the answer was "yes"). --- Additional comment from Daniel Veillard on 2011-06-22 23:14:19 EDT --- This should be fixed by the libvirt-0.9.2-1.el6 rebase --- Additional comment from Rita Wu on 2011-07-06 06:31:56 EDT --- Set it as VERIFIED per comment9 --- Additional comment from Laine Stump on 2011-09-28 02:26:23 EDT --- --- Additional comment from Yury V. Zaytsev on 2011-09-28 03:39:26 EDT --- Perfect, thanks! --- Additional comment from errata-xmlrpc on 2011-12-06 06:06:34 EST --- 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-2011-1513.html
The same problem exists under F19, libvirt-1.0.5.5-1.fc19.x86_64, virt-install-0.10.0-1.fc19.noarch, virt-manager-0.10.0-1.fc19.noarch. See screenshot. I suggest that the solution applied for RHEL6 be ported to F19.
In my case the ISO image was on a sambe share. Permissions were as follows: -rwxrwxrwx. 1 martin martin 4444913664 Jul 11 10:56 Fedora-19-x86_64-DVD.iso
Did you double-check that 'getsebool virt_use_samba' allows access to that share?
Thanks for the hint, I just figured that out myself. I changed it to setsebool virt_use_samba=1 and get the same error. If I mount the share with "uid=107,gid=107,noperm" with virt_use_samba=1, the ISO can be accessed by qemu, so that might count as a workaround, albeit not a very user-friendly one.
(In reply to Martin Wilck from comment #0) > Created attachment 802945 [details] > screenshot from virt-install on F19 > > commit 62ed801c13787cc844e75db7cd2d4c8a42454fcc This commit was pushed in v0.9.2, and therefore is already part of F19. If you are still seeing failure, it is unrelated to this particular issue. (In reply to Martin Wilck from comment #4) > Thanks for the hint, I just figured that out myself. > > I changed it to setsebool virt_use_samba=1 and get the same error. > > If I mount the share with "uid=107,gid=107,noperm" with virt_use_samba=1, > the ISO can be accessed by qemu, so that might count as a workaround, albeit > not a very user-friendly one. Indeed - if the file is already accessible, we should do a better job at ignoring chown() failure on a read-only mount. So it sounds like there may be more patches needed in this area; I'm wondering if it is related to bug 996543.
The problem is that libvirt's concept of "shared storage" doesn't include SMB or CIFS file systems, as can be easily seen by reading the code of virStorageFileIsSharedFSType(). It only regards NFS, GFS2, OCFS2, and AFS as "shared". For now, I can work around the problem by setting "dynamic_ownership = 0" in /etc/libvirt/qemu.conf. That's certainly not optimal but it works.
Try this patch that I just posted upstream. It *should* widens the scope of "shared" to include SMB filesystems (I'm currently unable to test it myself because I don't have any SMB filesystems locally). https://www.redhat.com/archives/libvir-list/2013-September/msg01572.html If it works for you, please respond to that message on the list. In the meantime I'm removing the bogus Blocks and Depends on the older BZs which were auto-created by the cloning process.
Thanks, but I guess you need not only include SMB but also CIFS CIFS_MAGIC_NUMBER 0xFF534D42 Martin
I just added CIFS_SUPER_MAGIC (which is the name I saw used elsewhere, although not present in the F19 /usr/include/linux/magic.h) and reposted upstream: https://www.redhat.com/archives/libvir-list/2013-September/msg01639.html
The patch appears to be ACKd upstream. Can we expect a bugfix package for Fedora any time soon?
commit e4e73337e5a5aa708bb356751404ab8ae6583f42 Author: Laine Stump <laine> Date: Thu Sep 26 05:40:17 2013 -0400 util: recognize SMB/CIFS filesystems as shared This should resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1012085 libvirt previously recognized NFS, GFS2, OCFS2, and AFS filesystems as "shared", and thus eligible for exceptions to certain rules/actions about chowning image files before handing them off to a guest. This patch widens the definition of "shared filesystem" to include SMB and CIFS filesystems (aka "Windows file sharing"); both of these use the same protocol, but different drivers so there are different magic numbers for each.
Cole, can we get this in the next f19 update?
(In reply to Dave Allan from comment #12) > Cole, can we get this in the next f19 update? Yes, now that it's in POST I'll pull it in for the next update
libvirt-1.0.5.7-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libvirt-1.0.5.7-2.fc19
Unfortunately, the patch doesn't seem to fix the problem. I was assuming that the code would pass qemuOpenFile() and from there, determine that the file was on shared CIFS storage. But that's not the case. The code never seems to call qemuOpenFile(). virStorageFileIsSharedFSType() is only called once from virSecuritySELinuxSetFileconHelper() with fstypes set to NFS only (this code path is only to hint at virt_use_nfs). The stack is virStorageFileIsSharedFSType virSecuritySELinuxSetFileconHelper virSecuritySELinuxSetFileconOptional virSecuritySELinuxSetSecurityFileLabel virDomainDiskDefForeachPath virSecuritySELinuxSetSecurityImageLabel virSecuritySELinuxSetSecurityAllLabel virSecurityManagerSetAllLabel virSecurityStackSetSecurityAllLabel virSecurityManagerSetAllLabel qemuProcessStart ... Later I hit the error in virSecurityDACSetOwnership() with this stack: virSecurityDACSetOwnership virSecurityDACSetSecurityFileLabel virDomainDiskDefForeachPath virSecurityDACSetSecurityImageLabel virSecurityDACSetSecurityAllLabel virSecurityManagerSetAllLabel virSecurityStackSetSecurityAllLabel virSecurityManagerSetAllLabel qemuProcessStart ...
I'm lost in the tree of security-related calls. But as a matter of fact, Laine, your patch doesn't seem to have any effect because the code is taking other paths where libvirt never actually checks for shared storage.
If you take a look at virSeucirytDACSetOwnership(), you'll see that special allowances are made for certain error returns from chown(). Perhaps a different errno is being returned by the CIFS driver when it fails to chown(), and all that's needed is an addition to that list of "accepted" errnos. I've just read back through this entire report and see that you've never included the exact error log that you receive on failure, only copied the one from the original BZ (which was reported about a failure to chown an image on an NFS share). The end of the message from your system would tell us the errno value being returned that we will need to check for.
Error starting domain: unable to set user and group to '107:107' on '/cifs/linux-install.qalab/iso/Fedora/Fedora-19-x86_64-DVD.iso': Permission denied Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 100, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 122, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1216, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 698, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: unable to set user and group to '107:107' on '/cifs/linux-install.qalab/iso/Fedora/Fedora-19-x86_64-DVD.iso': Permission denied
The error code is 13 (EACCES).
Created attachment 825645 [details] [PATCH] virSecurityDACSetOwnership: allow EACCES Based on your comments, I tried this patch. The startup error seems to be gone, so it seems to have been successful in the first place. But I can't do serious testing. Something in my own libvirt build seems to have been messed up (I can't see localhost in virt-manager any more when I log in a s normal user, and my VM idles with a black screen). Maybe I need to set some --with-XYZ flags to get the build right? One thing that confuses me is that virSecurityDACSetOwnership just considers a few error codes non-fatal, without even checking whether the file resides on shared storage. Most probably your previous patch wouldn't make any difference here.
Package libvirt-1.0.5.7-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.0.5.7-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21644/libvirt-1.0.5.7-2.fc19 then log in and leave karma (feedback).
I'm seeing this on an F20 VM host machine...but I'm almost sure I've attached CIFS-hosted ISOs to VMs on that box before, so perhaps this is a regression? [root@vmhost ~]# getsebool virt_use_samba virt_use_samba --> on [root@vmhost ~]# rpm -q libvirt libvirt-1.1.3.4-3.fc20.x86_64 [root@vmhost ~]# ls -l /share/data/isos/20/Fedora-20-x86_64-DVD.iso -rwxrwxrwx. 1 nobody nobody 4603248640 Dec 14 10:57 /share/data/isos/20/Fedora-20-x86_64-DVD.iso /share/data is a CIFS mount: //nas/Media on /share/data type cifs (blahblah) Try to start a VM with that ISO attached as the 'CD drive': Error starting domain: unable to set user and group to '107:107' on '/share/data/isos/20/Fedora-20-x86_64-DVD.iso': Permission denied Error starting domain: unable to set user and group to '107:107' on '/share/data/isos/20/Fedora-20-x86_64-DVD.iso': Permission denied Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1317, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 866, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: unable to set user and group to '107:107' on '/share/data/isos/20/Fedora-20-x86_64-DVD.iso': Permission denied
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.