| Summary: | [Svirt]The context of the save file is not correct | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | yanbing du <ydu> |
| Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.3 | CC: | acathrow, dallan, dyuan, eblake, gsun, mzhan, rwu, whuang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-04-02 10:07:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
I think this is an unintentional change, probably a side-effect of:
commit c8683f231dd227da8540f3249d7e332ec7a75ad7
Author: Jiri Denemark <jdenemar>
Date: Mon Feb 6 14:53:24 2012 +0100
qemu: Always use iohelper for dumping domain core
Qemu uses non-blocking I/O which doesn't play nice with regular file
descriptors. We need to pass a pipe to qemu instead, which can easily be
done using iohelper.
It was indeed unintentional but it was actually a bug fix :-) The "system_u:object_r:svirt_image_t:s0:c506,c657" context was actually an undesired side effect of relabeling file descriptor in a way that qemu can write to it. Since we now pass a pipe instead, the file's context is not affected. Also the old context didn't make sense at all with dynamic labeling once the domain shuts down. |
Description of problem: Save a running guest, the context of the save file is different with the expect result. The actual result is: system_u:object_r:virt_tmp_t:s0 The expect result is: system_u:object_r:svirt_image_t:s0 BTW, after downgrade libvirt from libvirt-0.9.10-1 to libvirt-0.9.10-0rc2, the result is correct. Not sure if this is a regression bug or new design result. Version-Release number of selected component (if applicable): libvirt-0.9.10-1.el6.x86_64 qemu-kvm-0.12.1.2-2.225.el6.x86_64 kernel-2.6.32-220.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start a normal guest and save it. # virsh save test /tmp/test.save Domain test saved to /tmp/test.save 2.Check the context of the save file. # ll -Z /tmp/test.save -rw-------. root root system_u:object_r:virt_tmp_t:s0 /tmp/test.save 3. Downgrade libvirt to libvirt-0.9.10-0rc2 and do step1 & step2 again. # virsh save test /tmp/test3.save Domain test saved to /tmp/test3.save # ll -Z /tmp/test3.save -rw-------. root root system_u:object_r:svirt_image_t:s0:c506,c657 /tmp/test3.save Actual results: the context of the save file is system_u:object_r:virt_tmp_t:s0 Expected results: the context of the save file should be system_u:object_r:svirt_image_t:s0 Additional info: SELinux is Enforcing. After upgrade libvirt back to libvirt-0.9.10-1, then save the guest, will get a different result: # virsh save test /tmp/test5.save Domain test saved to /tmp/test5.save # ll -Z /tmp/test5.save -rw-------. root root unconfined_u:object_r:virt_tmp_t:s0 /tmp/test5.save The security labels is added automatically, and default type is 'dynamic', following is the XML content after start the guest: ----new libvirt version---- <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c422,c458</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c422,c458</imagelabel> </seclabel> ---- ----old libvirt version---- <seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c570,c773</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c570,c773</imagelabel> </seclabel> ----