RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 924151 - block copy fail with permission denied error if original disk image located on NFS storage
Summary: block copy fail with permission denied error if original disk image located o...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 924153
TreeView+ depends on / blocked
 
Reported: 2013-03-21 09:56 UTC by yanbing du
Modified: 2016-02-02 02:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 924153 (view as bug list)
Environment:
Last Closed: 2014-04-04 20:58:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description yanbing du 2013-03-21 09:56:48 UTC
Description of problem:
Create a domain with the disk image located on NFS storage, then do blcok copy for this domain, and make sure the destination copy image not locate on the NFS storage, it will fail with permission denied. 

Version-Release number of selected component (if applicable):
libvirt-0.10.2-18.el6_4.2.x86_64 

How reproducible:
100% 

Steps to Reproduce:
1. Mount the NFS storage
# getenforce
Enforcing
# getsebool virt_use_nfs
virt_use_nfs --> on

# mount $nfs /mnt

2. Create a domain:
# virsh create test.xml
Domain vm1 created from test.xml

# virsh dumpxml vm1
<domain type='kvm' id='12'>
  <name>vm1</name>
  <uuid>de6e3e23-44db-2235-f779-b72dc0fc6da0</uuid>
  <memory unit='KiB'>131072</memory>
  <currentMemory unit='KiB'>131072</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='rhel6.4.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/vm30.img'>
        <seclabel model='selinux' relabel='no'/>
      </source>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
    <controller type='usb' index='0'>
      <alias name='usb0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c288,c802</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c288,c802</imagelabel>
  </seclabel>
</domain>


2. Do block copy for vda
# virsh blockcopy vm1 vda /tmp/vm1.img --wait --verbose
error: internal error unable to execute QEMU command '__com.redhat_drive-mirror': Could not open '/tmp/vm1.img': Permission denied

if change the destination path to nfs storage, it will pass
# virsh blockcopy vm1 vda /mnt/vm1.img --wait --verbose
Block Copy: [100 %]
Now in mirroring phase

# ll /mnt/vm1.img
-rw-------. 1 qemu qemu 5368709120 Mar 21  2013 /mnt/vm1.img
# virsh dumpxml vm1 |grep '<disk' -A 6
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/vm30.img'>
        <seclabel model='selinux' relabel='no'/>
      </source>
      <mirror file='/mnt/vm1.img' format='raw' ready='yes'/>
      <target dev='vda' bus='virtio'/> 

  
Actual results:
Step2,  if the destination copy image not locate on the NFS storage, it will fail with permission denied. 

Expected results:
Blockcopy can successful 

Additional info:
/var/log/libvirt/libvirtd.log
.......
2013-03-21 08:44:48.328+0000: 3191: error : qemuMonitorJSONCheckError:355 : internal error unable to execute QEMU command '__com.redhat_drive-mirror': Could not open '/tmp/vm1.img': Permission denied

Comment 2 Eric Blake 2013-08-20 17:10:00 UTC
Solved upstream with:

commit 95577af442e503bb209808b04b6482c895c9f561
Author: Eric Blake <eblake>
Date:   Tue Aug 13 14:19:14 2013 -0600

    selinux: enhance test to cover nfs label failure
    
    Daniel Berrange (correctly) pointed out that we should do a better
    job of testing selinux labeling fallbacks on NFS disks that lack
    labeling support.
    
    * tests/securityselinuxhelper.c (includes): Makefile already
    guaranteed xattr support.  Add additional headers.
    (init_syms): New function, borrowing from vircgroupmock.c.
    (setfilecon_raw, getfilecon_raw): Fake NFS failure.
    (statfs): Fake an NFS mount point.
    (security_getenforce, security_get_boolean_active): Don't let host
    environment affect test.
    * tests/securityselinuxlabeldata/nfs.data: New file.
    * tests/securityselinuxlabeldata/nfs.xml: New file.
    * tests/securityselinuxlabeltest.c (testSELinuxCreateDisks)
    (testSELinuxDeleteDisks): Setup and cleanup for fake NFS mount.
    (testSELinuxCheckLabels): Test handling of SELinux NFS denial.
    Fix memory leak.
    (testSELinuxLabeling): Avoid infinite loop on dirty tree.
    (mymain): Add new test.

commit 0f082e699eda0ad14965c0bc75789c4bfac2bda7
Author: Eric Blake <eblake>
Date:   Mon Aug 12 09:15:42 2013 -0600

    selinux: distinguish failure to label from request to avoid label
    
    https://bugzilla.redhat.com/show_bug.cgi?id=924153
    
    Commit 904e05a2 (v0.9.9) added a per-<disk> seclabel element with
    an attribute relabel='no' in order to try and minimize the
    impact of shutdown delays when an NFS server disappears.  The idea
    was that if a disk is on NFS and can't be labeled in the first
    place, there is no need to attempt the (no-op) relabel on domain
    shutdown.  Unfortunately, the way this was implemented was by
    modifying the domain XML so that the optimization would survive
    libvirtd restart, but in a way that is indistinguishable from an
    explicit user setting.  Furthermore, once the setting is turned
    on, libvirt avoids attempts at labeling, even for operations like
    snapshot or blockcopy where the chain is being extended or pivoted
    onto non-NFS, where SELinux labeling is once again possible.  As
    a result, it was impossible to do a blockcopy to pivot from an
    NFS image file onto a local file.
    
    The solution is to separate the semantics of a chain that must
    not be labeled (which the user can set even on persistent domains)
    vs. the optimization of not attempting a relabel on cleanup (a
    live-only annotation), and using only the user's explicit notation
    rather than the optimization as the decision on whether to skip
    a label attempt in the first place.  When upgrading an older
    libvirtd to a newer, an NFS volume will still attempt the relabel;
    but as the avoidance of a relabel was only an optimization, this
    shouldn't cause any problems.
    
    In the ideal future, libvirt will eventually have XML describing
    EVERY file in the backing chain, with each file having a separate
    <seclabel> element.  At that point, libvirt will be able to track
    more closely which files need a relabel attempt at shutdown.  But
    until we reach that point, the single <seclabel> for the entire
    <disk> chain is treated as a hint - when a chain has only one
    file, then we know it is accurate; but if the chain has more than
    one file, we have to attempt relabel in spite of the attribute,
    in case part of the chain is local and SELinux mattered for that
    portion of the chain.
    
    * src/conf/domain_conf.h (_virSecurityDeviceLabelDef): Add new
    member.
    * src/conf/domain_conf.c (virSecurityDeviceLabelDefParseXML):
    Parse it, for live images only.
    (virSecurityDeviceLabelDefFormat): Output it.
    (virDomainDiskDefParseXML, virDomainChrSourceDefParseXML)
    (virDomainDiskSourceDefFormat, virDomainChrDefFormat)
    (virDomainDiskDefFormat): Pass flags on through.
    * src/security/security_selinux.c
    (virSecuritySELinuxRestoreSecurityImageLabelInt): Honor labelskip
    when possible.
    (virSecuritySELinuxSetSecurityFileLabel): Set labelskip, not
    norelabel, if labeling fails.
    (virSecuritySELinuxSetFileconHelper): Fix indentation.
    * docs/formatdomain.html.in (seclabel): Document new xml.
    * docs/schemas/domaincommon.rng (devSeclabel): Allow it in RNG.
    * tests/qemuxml2argvdata/qemuxml2argv-seclabel-*-labelskip.xml:
    * tests/qemuxml2argvdata/qemuxml2argv-seclabel-*-labelskip.args:
    * tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-*-labelskip.xml:
    New test files.
    * tests/qemuxml2argvtest.c (mymain): Run the new tests.
    * tests/qemuxml2xmltest.c (mymain): Likewise.
    
    Signed-off-by: Eric Blake <eblake>

Comment 5 RHEL Program Management 2014-04-04 20:58:19 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.


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