Bug 712170 - QEMU DAC security driver should not chown of iso images (on NFS shares)
QEMU DAC security driver should not chown of iso images (on NFS shares)
Status: CLOSED DUPLICATE of bug 702044
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.1
All Linux
medium Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-09 13:08 EDT by Daniel Riek
Modified: 2011-09-28 02:26 EDT (History)
32 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 517304
Environment:
Last Closed: 2011-09-28 02:26:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Riek 2011-06-09 13:08:18 EDT
This problem appears to be affecting RHEL 6.1 as well. Making it essentially impossible for an average Enterprise to use install ISOs from a shared storage.

+++ This bug was initially created as a clone of Bug #517304 +++

Description of problem:
When trying to install a guest from an ISO file in an NFS-mounted directory I get this from virt-manager:

Error

Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: libvir: QEMU error : cannot set ownership on /mnt/cyberelk/Fedora-11-x86_64-DVD/Fedora-11-x86_64-DVD.iso: Read-only file system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error unable to start guest: libvir: QEMU error : cannot set ownership on /mnt/cyberelk/Fedora-11-x86_64-DVD/Fedora-11-x86_64-DVD.iso: Read-only file system

'

Version-Release number of selected component (if applicable):
virt-manager-0.8.0-1.fc12.noarch
libvirt-0.7.0-3.fc12.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Mount NFS directory with '-ocontext="system_u:object_r:virt_content_t:s0"
2.Install guest from ISO in that directory.
  
Actual results:
Error message.

Additional info:
$ mount | grep virt
cyberelk:/mnt/archive/rh on /mnt/cyberelk type nfs (rw,context="system_u:object_r:virt_content_t:s0",addr=192.168.2.1)

$ ls -l /mnt/cyberelk/Fedora-11-x86_64-DVD/
total 4172188
-rw-rw-r--. 1 twaugh twaugh       1620 2009-06-17 07:44 Fedora-11-x86_64-CHECKSUM
-rw-rw-r--. 1 root   root   4268124160 2009-06-18 00:06 Fedora-11-x86_64-DVD.iso
drwxr-xr-x. 2 root   root         4096 2009-07-22 17:04 loop

--- Additional comment from twaugh@redhat.com on 2009-08-13 09:09:42 EDT ---

Hacky workaround: export the NFS directory with 'rw,no_root_squash'.

--- Additional comment from twaugh@redhat.com on 2009-08-13 09:31:18 EDT ---

Actually I'm not so sure that even does work around it.  When booting a guest I get:

Booting from CD-Rom...
CDROM boot failure code : 0003
Boot failed: could not read the boot disk

FATAL: No bootable device.

(Of course, the ISO checksum is correct..)

--- Additional comment from berrange@redhat.com on 2009-08-13 09:37:45 EDT ---

A quick summary of what's going on here for the benefit of anyone using NFS

 - libvirt now runs QEMU as a 'qemu:qemu'  user/group pair, instead of root:root
 - libvirt will chown() disk images to this user pair when starting a guest to ensure they're accessible (similar to it setting SELinux labels)

Now for the problems you've exposed

 - If the NFS share is read-only, clearly we can't change ownership at all
 - If the NFS share is read-write, but root-squash, a libvirtd won't be able to change ownership because it gets squashed.

So

 - If the disk already has correct ownership, there's nothing for us todo, we should skip this chown step entirely

 - If the guest disk is read-only, we should treat this as non-fatal. The disk quite likely has world-read permission set which is more than sufficient.

 - If the guest disk is read-write, and has incorrect ownership, we have to try and change it, but if it fails there's nothing we can do. The admin will have to fix it.

There is one further problem wrt to NFS and the storage capabilities. Since libvirtd run as root, if you're using a libvirt storage pool based on NFS then its neccessary to have root squash disabled at this time

We need to figure out a way to let libvirt create files on NFS storage pools with the correct UID right from start, so that we don't ever need to chown things. Since libvirtd runs as root, this probably means we need to spawn a small helper program to create NFS files, which can change its UID to the desired target, avoiding the root squash issue.

In the mean time, there are two workarounds:

 - Use a writable NFS export with root squash disabled 

Or

 - Edit /etc/libvirt/qemu.conf and set it to run guest as user="root" and group="root", instead of qemu/qemu (ie reverting to < F11 behaviour)

The choice is yours based on whether security of host OS more important (change the NFS server), or security of NFS server more important (change QEMU to run as root).

--- Additional comment from markmc@redhat.com on 2009-08-14 14:58:22 EDT ---

dan: should we split some of this up into separate bugs?

--- Additional comment from twaugh@redhat.com on 2009-08-15 05:03:45 EDT ---

Neither work-around works for me actually.

Use writable NFS export with no_root_squash: see comment #2

Run guest as root:root: see bug #517619.

--- Additional comment from berrange@redhat.com on 2009-09-15 06:47:26 EDT ---

WRT to comment #5,  if you re-configured libvirtd to run qemu as root:root, we now automatically set directory ownership correctly.

WRT to comment #2, I believe that one is the bug caused by accidentally using virtio for CDROMs also now fixed.

So at least the two workarounds ought to be operational now. Leave this one open to track improving the logic in libvirtd though as per comment #3

--- Additional comment from markmc@redhat.com on 2009-10-02 11:33:34 EDT ---

*** Bug 526199 has been marked as a duplicate of this bug. ***

--- Additional comment from markmc@redhat.com on 2009-10-09 08:59:33 EDT ---

*** Bug 527102 has been marked as a duplicate of this bug. ***

--- Additional comment from yaneti@declera.com on 2009-11-08 02:28:36 EST ---

*** Bug 533649 has been marked as a duplicate of this bug. ***

--- Additional comment from markmc@redhat.com on 2009-11-19 08:13:58 EST ---

*** Bug 538527 has been marked as a duplicate of this bug. ***

--- Additional comment from markmc@redhat.com on 2009-11-19 08:31:05 EST ---

Note, the reporter of bug #538527 was having similar problems, but with using a samba mount

--- Additional comment from rubin@xs4all.nl on 2009-11-19 09:28:05 EST ---

Hi, I'm the reporter of #538527 (my first bugreport using abrt - I had not realized the coolness of abrt until now ;-).

I've tested the behaviour on my samba share and on an nfs share. Behaviour is indeed the same. When I copy the images to my desktop system you can see that libvirt changes the ownership of the files:

[rubin@inden Desktop]$ ls -l
total 6584024
-rw-r--r-- 1 qemu qemu 3204427776 2009-11-19 11:29 Fedora-12-i386-DVD.iso
-rw-r--r-- 1 qemu qemu 3537600512 2009-11-19 11:37 Fedora-12-x86_64-DVD.iso

The owner was previously rubin:users. The mode was previously 664.

--- Additional comment from agraham@g-b.net on 2010-01-01 18:41:38 EST ---

It's clear to me that libvirt should _not_ be changing the permissions of the source installation ISO image in the first place and this is the real bug.

By all means, change the ownership of the destination VM image (disk) being created, but not the source installation image or ISO.

A simply use case would be installing a VM from two or more different systems sharing an NFS based ISO image, in this case who owns the ISO image assuming the uid/gid differ on those systems.

The ISO image should have sufficient privileges to start with as set by the ADMIN otherwise contact your administrator (most likely yourself)

My guess is that the libvirt code just blindly sets the both the source and destination image permissions without much thought.


The Solution: Don't set the destination permissions from libvirt (or anything else)

and

if libvert cannot read the source image display a error message that humans can understand like "access denied" and not what it currently displays and I quote

"Unable to complete install: 'internal error unable to start guest: libvir: QEMU error : cannot set ownership on /datadisk/ISO/AsteriskNOW-1.5.0-i386-1of1.iso: Invalid argument"


The above message indicates another bug altogether, it implies I'm trying to start the image which I am not, I'm simply setting it up in virt-manager.

--- Additional comment from rjones@redhat.com on 2010-01-06 06:22:28 EST ---

I have to agree with comment 13 that libvirt(d) really shouldn't be in the
business of chowning files.  Even checking file permissions is dubious,
since to do a check you have to know everything about how file permissions,
SELinux, POSIX ACLs etc work.

--- Additional comment from berrange@redhat.com on 2010-01-06 07:06:06 EST ---

*** Bug 552858 has been marked as a duplicate of this bug. ***

--- Additional comment from petersen@redhat.com on 2010-01-17 20:32:27 EST ---

Any update?

--- Additional comment from triage@lists.fedoraproject.org on 2010-03-15 08:45:49 EDT ---


This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from jflorian@doubledog.org on 2010-03-28 13:34:21 EDT ---

I fully agree with comment #14 and comment #13.  It's very common to have a local mirror of the ISOs shared via NFS (or Samba) so that repeated downloads aren't necessary for everyone at that site.

My work around for now is to make a copy on the local host in /tmp from the NFS share, which is just plain silly, sad, and embarrassing.

--- Additional comment from petersen@redhat.com on 2010-04-29 22:16:04 EDT ---

Any chance of a fix in the F13 timeframe?  This is quite a pain point IMHO.

--- Additional comment from petersen@redhat.com on 2010-04-29 22:19:04 EDT ---

(Updating summary based on preceding comments.)

--- Additional comment from frankly3d@gmail.com on 2010-07-02 10:22:25 EDT ---

(In reply to comment #3)

>  - Edit /etc/libvirt/qemu.conf and set it to run guest as user="root" and
> group="root", instead of qemu/qemu (ie reverting to < F11 behaviour)
> 

This didn't work for me. same permission problem.
libvirt-0.7.7-5.fc13.x86_64
virt-manager-0.8.4-1.fc13.noarch

The nfs server is a NAS

--- Additional comment from gscarborough@gmail.com on 2010-07-06 21:40:25 EDT ---

Don't know if this is apparent to all people having this issue, but user qemu and group qemu MUST exist on the NFS server, or you can't set the permissions, even as root on a no_root_squash share.  I don't know if that is the way NFS is SUPPOSE to work or not.

--- Additional comment from frankly3d@gmail.com on 2010-07-07 04:22:43 EDT ---

(In reply to comment #22)
> Don't know if this is apparent to all people having this issue, but user qemu
> and group qemu MUST exist on the NFS server, or you can't set the permissions,
> even as root on a no_root_squash share.  I don't know if that is the way NFS is
> SUPPOSE to work or not.    


Once I did that I was fine:
Using the nas (nfs server) web-interface created user=qemu groups=qemu\kvm
also created a secure folder for qemu.
Transferred all ~/Torrents to this new folder.
Adjusted virt-host /etc/fstab to suit.
virthost$ su
chown -R qemu:kvm /new_path/to/Torrents.

no permission problems since

--- Additional comment from mmilgram@redhat.com on 2010-07-07 10:32:53 EDT ---

Why should the iso need to have special permissions for qemu or kvm?  Isn't it pretending the ISO is a CD?  As long as it can read the ISO, there should be no need to change ownership of it.

--- Additional comment from ichikawa@ilovex.co.jp on 2011-01-31 08:33:15 EST ---

I was embarrassed, too. 
However, I was able to 'not to change ownership' by editing the following parameter. 

 vi /etc/libvirt/qemu.conf
    139 # Whether libvirt should dynamically change file ownership
    140 # to match the configured user/group above. Defaults to 1.
    141 # Set to 0 to disable file ownership changes.
    142 #dynamic_ownership = 1
    143 dynamic_ownership = 0

But, where this side effect occurs is not understood. 
Is it good in this?

--- Additional comment from triage@lists.fedoraproject.org on 2011-06-02 13:50:27 EDT ---


This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

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 prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from petersen@redhat.com on 2011-06-03 04:01:45 EDT ---

Still happens with F15 as far as I can tell.
Comment 1 Daniel Riek 2011-06-09 13:18:21 EDT
One addition: if I understand NFS4 right, this bug means that the user QEMU has to actually exist on the storage server or at least be visible to idmap in the server - so in addition to having to allow qemu to chown files, you have to create users that should not have to exist.
Comment 3 Wayne Sun 2011-07-13 07:13:47 EDT
Build:
RHEL6.2-20110623.n.0
Packages:
# rpm -q libvirt virt-manager kernel
libvirt-0.9.3-2.el6.x86_64
virt-manager-0.8.6-4.el6.noarch
kernel-2.6.32-166.el6.x86_64


The nfs server is with (rw,no_root_squash)

Steps:
1. #setsebool virt_use_nfs on
This allows all virtual machine to read/write nfs share that do not specify a mount context.

2. mount the share
# mount -o context="system_u:object_r:virt_content_t:s0" 10.66.6.148:/var/lib/libvirt/images/ /mnt

3. check the label and chown
# ll -Z /mnt/
-rw-r--r--. qemu qemu system_u:object_r:nfs_t:s0       RHEL6.0-20100922.1-Server-x86_64-DVD1.iso

The chown is qemu:qemu, and label is not as set.

# mount |grep virt
10.66.90.121:/vol/S3/libvirtauto on /media type nfs (rw,addr=10.66.90.121)
10.66.6.148:/var/lib/libvirt/images/ on /mnt type nfs (rw,context="system_u:object_r:virt_content_t:s0",vers=4,addr=10.66.6.148,clientaddr=10.66.7.191)

but the label shows by mount is as set

4. In virt-manager choose install media from local iso, use /mnt/RHEL6.0-20100922.1-Server-x86_64-DVD1.iso

The installation success

There is no error of permission denied this way.
Comment 4 Wayne Sun 2011-07-13 07:21:29 EDT
Without set virt_use_nfs on in last comment.

the installation will fail at step 4, and permission denied error msg appear.

So, maybe this bug is related to:
Bug 589922 - permission denied error for NFS image, should libvirt error message mention virt_use_nfs? 
https://bugzilla.redhat.com/show_bug.cgi?id=589922
Comment 5 Daniel Riek 2011-07-13 09:43:38 EDT
The problem is not SELinux-related. It's that libvirt takes *ownership* of the file, fails if it can't. - All of which creates multiple problems and is completely unnecessary.
Comment 6 Yury V. Zaytsev 2011-07-29 12:39:49 EDT
Hi!

I am also annoyed by the fact that libvirt changes the ownership and SELinux security type of the ISO files.

It doesn't matter whether it happens on the NFS shares or not, but on the NFS shares it's particularly harmful, because it causes a failure as stated by the reporter.

To my mind, there is no reason why libvirt would need to be able to write to the *read-only* ISO images as long as it does have read access to them, and also, potentially, this might lead to privilege escalation issues.

FYI, I have found a patch to work around this issue:

https://launchpadlibrarian.net/61177315/debdiff

This is already included in latest Ubuntu, however, I feel that it might be incomplete, because it doesn't seem to check whether there are read flags on; but whatever, let the competent people to find out the correct solution to this problem.

Thanks,
Z.
Comment 7 Laine Stump 2011-09-28 02:26:23 EDT
If you look at the function virSecurityDACSetOwnership() (which is what is doing the chowning), you will see that it does the following if the chown fails:

1) it will check the current owner/group of the file, and if it matches the qemu user/group, it will return success

2) it will check if the errno of the failed chown is EOPNOTSUPP or EINVAL, and if so will log an INFO message saying that the file system doesn't support chowning the file, but still return success.

Item (2) is explained more fully in Bug 702044 (reported against RHEL6.1, fixed in libvirt-0.9.2-1), which is *very* similar to this bug.

Just to verify that this is a non-issue, I ran the following test:

1) mount an NFS share containing ISO images with both r/o and root_squash turned on.

2) Attempt installing a guest using one of those ISO images which was owned by qemu:qemu - SUCCESS.

3) Attempt mounting a different ISO image owned by root:root (permissions 0644) on an existing guest - SUCCESS.

As far as I can see, this bug is reporting the same issue as Bug 702044, and was fixed as of libvirt-0.9.2-1.

*** This bug has been marked as a duplicate of bug 702044 ***

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