Bug 1012085 - Can't attach iso from CIFS filesystem to VM because it can't be chowned
Can't attach iso from CIFS filesystem to VM because it can't be chowned
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
19
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Laine Stump
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1030862
  Show dependency treegraph
 
Reported: 2013-09-25 12:38 EDT by Martin Wilck
Modified: 2016-04-26 20:08 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 702044
Environment:
Last Closed: 2015-02-17 12:20:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
screenshot from virt-install on F19 (48.19 KB, image/png)
2013-09-25 12:38 EDT, Martin Wilck
no flags Details
[PATCH] virSecurityDACSetOwnership: allow EACCES (1023 bytes, patch)
2013-11-18 08:59 EST, Martin Wilck
no flags Details | Diff

  None (edit)
Description Martin Wilck 2013-09-25 12:38:19 EDT
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@laine.org>
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
Comment 1 Martin Wilck 2013-09-25 12:40:31 EDT
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.
Comment 2 Martin Wilck 2013-09-25 12:42:01 EDT
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
Comment 3 Eric Blake 2013-09-25 12:48:42 EDT
Did you double-check that 'getsebool virt_use_samba' allows access to that share?
Comment 4 Martin Wilck 2013-09-25 12:59:33 EDT
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.
Comment 5 Eric Blake 2013-09-25 13:05:15 EDT
(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.
Comment 6 Martin Wilck 2013-09-26 04:15:02 EDT
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.
Comment 7 Laine Stump 2013-09-26 05:46:58 EDT
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.
Comment 8 Martin Wilck 2013-09-26 06:21:46 EDT
Thanks, but I guess you need not only include SMB but also CIFS

              CIFS_MAGIC_NUMBER     0xFF534D42
 
Martin
Comment 9 Laine Stump 2013-09-27 07:24:53 EDT
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
Comment 10 Martin Wilck 2013-11-15 10:06:30 EST
The patch appears to be ACKd upstream. Can we expect a bugfix package for Fedora any time soon?
Comment 11 Eric Blake 2013-11-15 10:09:05 EST
commit e4e73337e5a5aa708bb356751404ab8ae6583f42
Author: Laine Stump <laine@laine.org>
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.
Comment 12 Dave Allan 2013-11-15 11:24:50 EST
Cole, can we get this in the next f19 update?
Comment 13 Cole Robinson 2013-11-16 15:50:44 EST
(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
Comment 14 Fedora Update System 2013-11-17 18:29:18 EST
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
Comment 15 Martin Wilck 2013-11-18 06:25:10 EST
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
         ...
Comment 16 Martin Wilck 2013-11-18 06:33:19 EST
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.
Comment 17 Laine Stump 2013-11-18 07:11:06 EST
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.
Comment 18 Martin Wilck 2013-11-18 08:20:13 EST
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
Comment 19 Martin Wilck 2013-11-18 08:23:56 EST
The error code is 13 (EACCES).
Comment 20 Martin Wilck 2013-11-18 08:59:48 EST
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.
Comment 21 Fedora Update System 2013-11-19 00:22:43 EST
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).
Comment 22 Adam Williamson 2014-03-21 13:23:31 EDT
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
Comment 23 Fedora End Of Life 2015-01-09 14:58:36 EST
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.
Comment 24 Fedora End Of Life 2015-02-17 12:20:40 EST
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.

Note You need to log in before you can comment on or make changes to this bug.