Bug 1151718

Could you please attach the full debug log.

Created attachment 946274 [details]
libvirtd log

I'm suspecting that the denial may be caused by selinux. Could you please look into the audit log for a possible clue?.

Yeah, it should be selinux's problem


# virsh snapshot-create-as rhel6 s1 --diskspec vda,file=/var/lib/libvirt/images/rhel6.s1 --disk-only 
error: internal error: unable to execute QEMU command 'transaction': Could not create file: Permission denied

# ausearch -m avc -ts recent
----
time->Tue Nov 11 12:50:21 2014
type=SYSCALL msg=audit(1415681421.162:7324): arch=c000003e syscall=2 success=no exit=-13 a0=7f8fffd360b0 a1=80800 a2=0 a3=7f8ff6d10020 items=0 ppid=1 pid=14759 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c25,c329 key=(null)
type=AVC msg=audit(1415681421.162:7324): avc:  denied  { read } for  pid=14759 comm="qemu-kvm" name="rhel6.s1" dev="sda1" ino=1707175 scontext=system_u:system_r:svirt_t:s0:c25,c329 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
----
time->Tue Nov 11 12:50:21 2014
type=SYSCALL msg=audit(1415681421.162:7325): arch=c000003e syscall=2 success=no exit=-13 a0=7f8fffd360b0 a1=80800 a2=0 a3=7f8ff6d10020 items=0 ppid=1 pid=14759 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c25,c329 key=(null)
type=AVC msg=audit(1415681421.162:7325): avc:  denied  { read } for  pid=14759 comm="qemu-kvm" name="rhel6.s1" dev="sda1" ino=1707175 scontext=system_u:system_r:svirt_t:s0:c25,c329 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
----
time->Tue Nov 11 12:50:21 2014
type=SYSCALL msg=audit(1415681421.168:7326): arch=c000003e syscall=2 success=no exit=-13 a0=7f8fffdba4d0 a1=80800 a2=0 a3=7f8ff6d10de0 items=0 ppid=1 pid=14759 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c25,c329 key=(null)
type=AVC msg=audit(1415681421.168:7326): avc:  denied  { read } for  pid=14759 comm="qemu-kvm" name="rhel6.s1" dev="sda1" ino=1707175 scontext=system_u:system_r:svirt_t:s0:c25,c329 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
----
time->Tue Nov 11 12:50:21 2014
type=SYSCALL msg=audit(1415681421.168:7327): arch=c000003e syscall=2 success=no exit=-13 a0=7f8fffdba4d0 a1=80800 a2=0 a3=7f8ff6d10de0 items=0 ppid=1 pid=14759 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c25,c329 key=(null)
type=AVC msg=audit(1415681421.168:7327): avc:  denied  { read } for  pid=14759 comm="qemu-kvm" name="rhel6.s1" dev="sda1" ino=1707175 scontext=system_u:system_r:svirt_t:s0:c25,c329 tcontext=system_u:object_r:virt_image_t:s0 tclass=file
----
time->Tue Nov 11 12:50:21 2014
type=SYSCALL msg=audit(1415681421.168:7328): arch=c000003e syscall=2 success=no exit=-13 a0=7f8fffdba460 a1=80241 a2=1a4 a3=7f8ff6d107a0 items=0 ppid=1 pid=14759 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c25,c329 key=(null)
type=AVC msg=audit(1415681421.168:7328): avc:  denied  { write } for  pid=14759 comm="qemu-kvm" name="rhel6.s1" dev="sda1" ino=1707175 scontext=system_u:system_r:svirt_t:s0:c25,c329 tcontext=system_u:object_r:virt_image_t:s0 tclass=file

Fixed upstream:

commit 7e130e8b3505ce0f821081dffde8c13a7ff921b3
Author: Peter Krempa <pkrempa>
Date:   Wed Nov 19 18:54:43 2014 +0100

    storage: qemu: Fix security labelling of new image chain elements
    
    When creating a disk image snapshot the libvirt code would blindly copy
    the parents label to the newly created image. This runs into problems
    when you start a VM from an image hosted on NFS (or other storage system
    that doesn't support selinux labels) and the snapshot destination is on
    a storage system that does support selinux labels. Libvirt's code in
    that case generates a different security label for the image hosted on
    NFS. This label is valid only for NFS images and doesn't allow access in
    case of a locally stored image.
    
    To fix this issue libvirt needs to refrain from copying security
    information in cases where the default domain seclabel is a better
    choice.
    
    This patch repurposes the now unused @force argument of
    virStorageSourceInitChainElement to denote whether a copy of the
    security labelling stuff should be attempted or not. This allows to
    fine-control the copy operation for cases where we need to keep the
    label of the old disk vs. the cases where we need to keep the label
    unset to use the default domain imagelabel.

I can't verify this bug, since there is other failed case.

If guest source file is based on NFS, then create external snapshot with new snapshot file also be based on NFS, will met permission error.

1.

# getenforce && getsebool virt_use_nfs
Enforcing
virt_use_nfs --> on


2. mount nfs to local

# mount -o soft 10.66.x.xxx:/mnt/nfs /mnt/

3. start guest with source file based on nfs

# virsh domblklist r7 ;virsh start r7 
Target     Source
------------------------------------------------
vda        /mnt/rhel6.img

Domain r7 started

4. create external snapshot with new file also based on nfs

# virsh snapshot-create-as r7 ss --disk-only 
error: internal error: unable to execute QEMU command 'transaction': Could not create file: Permission denied

5. create external snapshot with new file based on local

# virsh snapshot-create-as r7 ss --disk-only --diskspec vda,file=/var/lib/libvirt/images/r7.ss 
Domain snapshot ss created

# virsh dumpxml r7|grep disk -A 8
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/r7.ss'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/mnt/rhel6.img'/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>

(In reply to Shanzhi Yu from comment #8)
> I can't verify this bug, since there is other failed case.
> 
> If guest source file is based on NFS, then create external snapshot with new
> snapshot file also be based on NFS, will met permission error.
> 
> 1.
> 
> # getenforce && getsebool virt_use_nfs
> Enforcing
> virt_use_nfs --> on
> 
> 
> 2. mount nfs to local
> 
> # mount -o soft 10.66.x.xxx:/mnt/nfs /mnt/
> 
> 3. start guest with source file based on nfs
> 
> # virsh domblklist r7 ;virsh start r7 
> Target     Source
> ------------------------------------------------
> vda        /mnt/rhel6.img
> 
> Domain r7 started
> 
> 4. create external snapshot with new file also based on nfs
> 
> # virsh snapshot-create-as r7 ss --disk-only 
> error: internal error: unable to execute QEMU command 'transaction': Could
> not create file: Permission denied
> 

I can't reproduce that by the steps you've described here. Could you please attach the following info:
1) libvirtd debug log
2) selinux audit log
3) mount options of the mount point (export)
4) ls -lia of the mount point

1. libvirtd log is attached

2. selinux audit log

# ausearch -m avc -ts recent
<no matches>

audit.log also be attached.

3. mount options
3.1 on nfs server
# cat /etc/exports
#/mnt/nfs *(async,rw,all_squash,anonuid=107,anonuid=107)
# *(rw,no_root_squash)
/mnt/nfs *(rw)

3.2 on client

# mount|grep /mnt
10.66.6.111:/mnt/nfs on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.66.4.110,local_lock=none,addr=10.66.6.111)

4. ls mount
# ls -lia /mnt/
total 5042244
2237486 drwxrwxrwx.  2 root      root            4096 Nov 28 15:41 .
      2 dr-xr-xr-x. 20 root      root            4096 Nov 27 18:03 ..
2237487 -rwxrwxrwx.  1 qemu      qemu      3482714112 Nov 28 15:44 rhel6.img
2259106 -rw-------.  1 qemu      nfsnobody  393216000 Oct 15 14:53 rhel6.t2

Created attachment 962397 [details]
logoflibvirtd

Created attachment 962398 [details]
logofaudit

(In reply to Shanzhi Yu from comment #11)
> Created attachment 962397 [details]
> logoflibvirtd

The log doesn't contain section where the snapshot fails. Please attach the correct log.

Created attachment 963483 [details]
Log of Libvirtd

I try again with libvirt-1.2.8-11.el7.x86_64, after many times test, I can't reproduce this bug again. 
So change this to VERIFIED status

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.

https://rhn.redhat.com/errata/RHSA-2015-0323.html