Bug 229283

Summary:	xen installation mislabels /etc/services
Product:	[Fedora] Fedora	Reporter:	Davide Bolcioni <davide_bolcioni>
Component:	kernel-xen	Assignee:	Xen Maintainance List <xen-maint>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	bstein, dwalsh, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-02-21 15:33:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Davide Bolcioni 2007-02-19 22:21:28 UTC

+++ This bug was initially created as a clone of Bug #188689 +++

I encountered the same problem seen in the original report, mislabeling of
/etc/services causing syslog to fail:

root@avalon ~]# ls -Z /etc/services
-rw-r--r--  root root user_u:object_r:rpm_script_tmp_t /etc/services
[root@avalon ~]# restorecon -v /etc/services
restorecon reset /etc/services context 
user_u:object_r:rpm_script_tmp_t:s0->system_u:object_r:etc_t:s0

but I believe that the culprit is one of the following:

kernel-xen xen virt-manager libvirt python-virtinstall libvirt-python xen-libs 
gnome-python2-gnomekeyring bridge-utils


I wanted to experiment with xen, attempted

  yum install kernel-xen xen virt-manager

and the reboot into a xen kernel resulted in said problem, which persisted 
even after rebooting into the standard FC6 kernel.

Versions of involved components:
kernel-xen-2.6.19-1.2911.fc6
xen-3.0.3-3.fc6
virt-manager-0.2.6-3.fc6
libvirt-0.1.11-1.fc6
python-virtinst-0.98.0-1.fc6
libvirt-python-0.1.11-1.fc6
xen-libs-3.0.3-3.fc6
gnome-python2-gnomekeyring-2.16.0-1.fc6
bridge-utils-1.1-2

I tried "rpm -q --scripts" on each of the above, and only kernel-xen, 
virt-manager and xen have something of note. I tried yum remove followed by 
the yum install above, but the labeling of /etc/services was not affected.

Comment 1 Davide Bolcioni 2007-02-19 23:07:47 UTC

Sorry for wasting everybody's time, but I jumped the gun in the report above; 
the actual offender is

  VMware-server-1.0.1-29996.i386.rpm

which tampers with /etc/services upon installation and uninstallation, editing 
it using a 'mv' off a temporary file (this would explain the labeling). I just 
verified this.

Comment 2 Daniel Walsh 2007-02-21 15:33:19 UTC

Could you report a bug to them.  They can just do a restorecon in their post if
they 
restorecon /etc/services 

which will fix.