Bug 631981 - Suspending VMware virtual machines is slow or fails when selinux is enabled.
Summary: Suspending VMware virtual machines is slow or fails when selinux is enabled.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-08 19:38 UTC by Ninad Ghodke
Modified: 2010-09-22 00:38 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-3.7.19-57.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of: 631523
Environment:
Last Closed: 2010-09-22 00:38:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ninad Ghodke 2010-09-08 19:38:41 UTC
This should affect fedora 14 also..

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

Created attachment 445773 [details]
audit.log

Description of problem:
This is tested using VMware Workstation 7.1.1 but applies to all the VMware products, this also applies to Fedora 13.


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


How reproducible:
All the time.

Steps to Reproduce:
Using VMware Workstatino 7.1
1.Install RHEL6 in a VM.
2.Install tools after OS installation is complete.
3.Suspend the VM with the option or run the suspend script.

  
Actual results:
The VM does not suspend immediately. 
When the suspend command is issued, vmtoolsd which runs inside the VM executes the suspend script and the suspend script quiesces the networkmanager and brings down the network interfaces. But the dbus-send is unable to talk to the network-manager.

I shouldn't be able to see the process tree of when this happens... but I am able to see this.

oot 9918 0.0 0.3 60428 3108 ? Sl Jul30 2:40 /usr/sbin/vmtoolsd
root 26001 0.3 0.1 108136 1340 ? S 14:59 0:00 \_ /bin/sh /etc/vmware-tools/suspend-vm-default
root 26011 0.3 0.1 108400 1344 ? S 14:59 0:00 \_ /bin/sh /etc/vmware-tools/suspend-vm-default
root 26027 0.3 0.1 108396 1668 ? S 14:59 0:00 \_ /bin/bash ./ifdown ifcfg-lo
root 26033 0.0 0.0 108396 888 ? S 14:59 0:00 \_ /bin/bash ./ifdown ifcfg-lo
root 26034 0.3 0.1 51632 1976 ? S 14:59 0:00 \_ nmcli -t --fields running nm status
[root@localhost tmp]# strace -p 26034
Process 26034 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
writev(5, [{"l\1\0\1.\0\0\0\17\0\0\0\220\0\0\0\1\1o\0\37\0\0\0/org/fre"..., 160}, {"\36\0\0\0org.freedesktop.NetworkManag"..., 46}], 2) = 206
poll([{fd=5, events=POLLIN}], 1, 15000) = 0 (Timeout)
fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f83a295a000
writev(5, [{"l\1\1\1\214\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\207\0\0\0type='signal',sender='org.fr"..., 140}], 2) = 284
writev(5, [{"l\1\1\1\256\0\0\0\21\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\251\0\0\0type='signal',sender='org.fr"..., 174}], 2) = 318
writev(5, [{"l\1\1\1n\0\0\0\22\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"i\0\0\0type='signal',sender='org.fr"..., 110}], 2) = 254
writev(5, [{"l\1\1\1\244\0\0\0\23\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\237\0\0\0type='signal',sender='org.fr"..., 164}], 2) = 308
writev(5, [{"l\1\1\1\215\0\0\0\24\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\210\0\0\0type='signal',sender='org.fr"..., 141}], 2) = 285
writev(5, [{"l\1\1\1\256\0\0\0\25\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\251\0\0\0type='signal',sender='org.fr"..., 174}], 2) = 318
write(1, "running\n", 8) = 8
exit_group(0) = ?
Process 26034 detached



Expected results:
The VM should have suspended immediately.

Additional info:
To work around this.
1. I copied over just the single line in audit.log that has to do with dbus-send... see audit.log attached in the bug report.
2. cat /tmp/audit.log | audit2allow -M vmwareToolsSuspendResume 
3. semodule -i vmwareToolsSuspendResume.pp

so after this policy was installed the suspend resume script started working again.


the local.te file is

module vmwareToolsSuspendResume 1.0;

require {
	type NetworkManager_t;
	type init_t;
	class dbus send_msg;
}

#============= NetworkManager_t ==============

allow NetworkManager_t init_t:dbus send_msg;

--- Additional comment from dwalsh on 2010-09-08 11:20:34 EDT ---

Miroslav add

	init_dbus_chat(NetworkManager_t)

Comment 1 Miroslav Grepl 2010-09-09 11:42:14 UTC
Fixed in selinux-policy-3.7.19-55.fc13

Comment 2 Fedora Update System 2010-09-13 16:08:41 UTC
selinux-policy-3.7.19-57.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-57.fc13

Comment 3 Fedora Update System 2010-09-15 05:29:56 UTC
selinux-policy-3.7.19-57.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-57.fc13

Comment 4 Ninad Ghodke 2010-09-21 06:21:22 UTC
VMware QA has verified that this fixes the issue.

thanks for the quick response.

Comment 5 Fedora Update System 2010-09-22 00:37:23 UTC
selinux-policy-3.7.19-57.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


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