Bug 706000 - Guest should be started without a svirt label when disable "security_driver" in qemu.conf
Summary: Guest should be started without a svirt label when disable "security_driver" ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt
Version: 5.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-19 06:50 UTC by Cui Chun
Modified: 2011-05-19 08:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 08:48:39 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Cui Chun 2011-05-19 06:50:01 UTC
Description of problem:

After libvirtd and the guest are restarted, the guest should be without a svirt label when disable "security_driver" in qemu.conf for the running guest.


Version-Release number of selected component (if applicable):

libvirt-0.8.2-20.el5
libvirt-python-0.8.2-20.el5
kvm-83-232.el5


How reproducible:

Always

Steps to Reproduce:
1.Make sure selinux is enabled on OS

# getenforce 
Enforcing

2. Start a guest named vm1 with /var/lib/libvirt/images/w2k3-kvm2.img

# virsh list --all
 Id Name                 State
----------------------------------
  3 vm1                  running

# ll -Z /var/lib/libvirt/images/w2k3-kvm2.img 
-rw-------  root root system_u:object_r:svirt_image_t:s0:c536,c666 /var/lib/libvirt/images/w2k3-kvm2.img

# virsh dominfo vm1
Id:             3
Name:           vm1
UUID:           c7ea7211-ed47-9dbf-c58e-18b251125fa6
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       20.5s
Max memory:     2097152 kB
Used memory:    2097152 kB
Persistent:     yes
Autostart:      disable
Security model: selinux
Security DOI:   0
Security label: system_u:system_r:svirt_t:s0:c536,c666 (enforcing)

3. Disable sVirt via /etc/libvirt/qemu.conf with setting security_driver="none"
4.Re-start libvirtd service and restart guest

# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

# virsh destroy vm1
Domain vm1 destroyed
# virsh start vm1
Domain vm1 started

5. Check the guest info

--Security info has been removed from dominfo
# virsh dominfo vm1
Id:             4
Name:           vm1
UUID:           c7ea7211-ed47-9dbf-c58e-18b251125fa6
OS Type:        hvm
State:          running
CPU(s):         1
CPU time:       20.8s
Max memory:     2097152 kB
Used memory:    2097152 kB
Persistent:     yes
Autostart:      disable

--But svirt label is still kept for image file
# ll -Z /var/lib/libvirt/images/w2k3-kvm2.img 
-rw-------  root root system_u:object_r:svirt_image_t:s0:c536,c666 /var/lib/libvirt/images/w2k3-kvm2.img


6. Even if stop guest, svirt label is still kept.

# virsh destroy vm1
Domain vm1 destroyed

# ll -Z /var/lib/libvirt/images/w2k3-kvm2.img 
-rw-------  root root system_u:object_r:svirt_image_t:s0:c536,c666 /var/lib/libvirt/images/w2k3-kvm2.img


7. Retry for a stop guest, the svirt label can be removed correctly in step 5.

# ll -Z /var/lib/libvirt/images/w2k3-kvm2.img 
-rw-------  root root system_u:object_r:virt_image_t   /var/lib/libvirt/images/w2k3-kvm2.img

  
Actual results:

The result in Step5

Expected results:

Enhance for running guest.

Additional info:

Comment 1 Daniel Berrangé 2011-05-19 08:48:39 UTC
4.Re-start libvirtd service and restart guest

# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

# virsh destroy vm1
Domain vm1 destroyed
# virsh start vm1
Domain vm1 started



This is the wrong order. It needs to be

  virsh destroy vm1
  service libvirtd restart
  virsh strat vm1


Since your example turned off svirt, before stopping the VM, libvirt no longer thinks that it has to reset the sVirt labels.


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