Bug 1012085

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.