This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 474182 - LVs created in an existing VG have wrong SELinux label
LVs created in an existing VG have wrong SELinux label
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F11VirtTarget 494832
  Show dependency treegraph
 
Reported: 2008-12-02 12:37 EST by Patrick C. F. Ernzer
Modified: 2009-08-05 12:35 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-05 12:35:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Patrick C. F. Ernzer 2008-12-02 12:37:04 EST
Description of problem:
if one creates a volume in a pool that is an existing VG, the SELinux context is not set correctly

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


How reproducible:
always

Steps to Reproduce:
1. open virt-manager
2. have a storage pool that is an existing Volume Group with free Physical Extents (VG_x60_internal in my case)
3. create a new volume (eg. KVM_test) in that pool
  
Actual results:
# ls -lZ /dev/mapper/VG_x60_internal-KVM_test 
brw-------  root root system_u:object_r:fixed_disk_device_t:s0 /dev/mapper/VG_x60_internal-KVM_test

Expected results:
system_u:object_r:virt_image_t:s0

Additional info:
I do understand that this is a difficult case as my existing VG also has LVs for / and swap and we definitely do not want to change the context of these, but new volumes created in the GUI should be labelled with the correct context.
Comment 1 Patrick C. F. Ernzer 2008-12-02 12:38:17 EST
oops, forgot the versions:
libvirt-0.4.6-3.fc10.x86_64
virt-manager-0.6.0-3.fc10.x86_64
Comment 2 Jerry Amundson 2009-03-02 14:25:27 EST
I have a different scenario, with the same result. In rawhide pre-f11,  Filesystem Directory pools, whether or not the directory exists or is created by virt-manager, are not given "virt_image_t". Startup of VM's using image files created in the pool then fail do to AVC devials.
libvirt-0.6.0-4.fc11.x86_64
libvirt-python-0.6.0-4.fc11.x86_64
python-virtinst-0.400.1-1.fc11.noarch
virt-manager-0.6.1-2.fc11.x86_64

Should this be a seperate BZ?
Comment 3 Mark McLoughlin 2009-03-25 14:11:22 EDT
I think this is similar to bug #491245 and should be fixed in rawhide. Please re-open if not

*** This bug has been marked as a duplicate of bug 491245 ***
Comment 4 Patrick C. F. Ernzer 2009-04-22 08:11:13 EDT
It would seem this is not fixed.

qemu-0.10-8.fc11.x86_64
libvirt-0.6.2-2.fc11.x86_64
virt-manager-0.7.0-4.fc11.x86_64

created a volume as per initial description.

# ls -lZ /dev/mapper/vg_bcblade02-KVM_test 
brw-------. root root system_u:object_r:fixed_disk_device_t:s0 /dev/mapper/vg_bcblade02-KVM_test
Comment 5 Bug Zapper 2009-06-09 06:05:07 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Daniel Berrange 2009-08-05 11:18:48 EDT
Creating LVM volumes with a particular label while nice, shouldn't really impact running of guests using the volume.  Whenever you start a KVM guest in Fedora 11, libvirt will automatically set the correct label on all disks.

So what actual problem is this lack of labelling causing you ?
Comment 7 Patrick C. F. Ernzer 2009-08-05 12:35:07 EDT
my bad, should have CLOSED CURRENTRELEASE this.
with F11
qemu-kvm-0.10.5-3.fc11.x86_64
libvirt-0.6.2-13.fc11.x86_64
virt-manager-0.7.0-5.fc11.x86_64

I can now create LVs in the virt-manager GUI and use them. Previously the wrong labelling was preventing use of the freshly created LVs.

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