Bug 823857
Summary: | guest can't start with unable to set security context error if guests are unconfined | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | yanbing du <ydu> | ||||||
Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 6.3 | CC: | acathrow, dallan, dyasny, dyuan, gsun, mzhan, rwu | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | libvirt-0.10.0-0rc0.el6 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 853043 (view as bug list) | Environment: | |||||||
Last Closed: | 2013-02-21 07:15:18 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 853043 | ||||||||
Attachments: |
|
Description
yanbing du
2012-05-22 10:21:55 UTC
Hmm, I wasn't able to reproduce this issue, everything works as expected. What is the output of virsh dumpxml --inactive rhel62 | grep seclabel -A 3 ? (In reply to comment #4) > Hmm, I wasn't able to reproduce this issue, everything works as expected. > What is the output of virsh dumpxml --inactive rhel62 | grep seclabel -A 3 ? Hi, Jiri I can always reproduce this bug. And after destroy the guest, the output of command virsh dumpxml --inactive rhel62 | grep seclabel -A 3 is empty. The packages i uesd are: kernel-2.6.32-279.2.1.el6.x86_64 libvirt-0.9.10-21.el6_3.3.x86_64 qemu-kvm-rhev-0.12.1.2-2.295.el6.x86_64 Created attachment 599675 [details]
guest XML file
Hmm, that's interesting. Could you catch debug logs from libvirtd while trying to start a domain with security_default_confined=0? Created attachment 599925 [details]
libvirtd debug log
config libvirtd.conf with:
log_level = 1
log_outputs="1:file:/tmp/libvirtd.log"
Oops, I didn't have any disks configured in my domain, which means there was nothing to relable in the first place. I can reproduce the issue now. Actually, the seclabel is correctly set to "none", you just need to swap steps 4 and 5 sinc seclabel of running domains doesn't change. However, even if domain seclabel is "none", we still try to generate and use image label for disks. This issue should be fixed by https://www.redhat.com/archives/libvir-list/2012-July/msg01385.html The patch from comment 10 was wrong. Anyway, this is now fixed upstream by v0.9.13-207-gce53382: commit ce53382ba28179d3a504b29b4f888b6e130d53f0 Author: Jiri Denemark <jdenemar> Date: Wed Jul 25 14:38:27 2012 +0200 security: Skip labeling resources when seclabel defaults to none If a domain is explicitly configured with <seclabel type="none"/> we correctly ensure that no labeling will be done by setting norelabel=true. However, if no seclabel element is present in domain XML and hypervisor is configured not to confine domains by default, we only set type to "none" without turning off relabeling. Thus if such a domain is being started, security driver wants to relabel resources with default label, which doesn't make any sense. Moreover, with SELinux security driver, the generated image label lacks "s0" sensitivity, which causes setfilecon() fail with EINVAL in enforcing mode. pkgs: # rpm -q libvirt qemu-kvm-rhev kernel libvirt-0.10.0-0rc0.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.297.el6_3.x86_64 kernel-2.6.32-291.el6.x86_64 steps: Following exact steps in description, step 5: # virsh start aaa Domain aaa started # virsh dumpxml aaa|grep seclabel -A 3 <seclabel type='none'/> </domain> # ll -Z /var/lib/libvirt/images/rhel6u2.qcow2 -rw-r--r--. qemu qemu system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel6u2.qcow2 This is working now. 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/RHSA-2013-0276.html |