[libvirt] I have no idea why the current version of libvirt works for anyone in enforcing mode.

Daniel P. Berrange berrange at redhat.com
Tue Mar 17 15:52:08 UTC 2009

On Fri, Mar 13, 2009 at 10:19:44AM +0000, Daniel P. Berrange wrote:
> On Thu, Mar 12, 2009 at 01:39:13PM -0400, Daniel J Walsh wrote:
> > Libvirt is executing qemu requiring it to execute pulseaudio which would 
> > require the folowing permissions,
> > 
> > #============= svirt_t ==============
> > allow svirt_t admin_home_t:dir setattr;
> > allow svirt_t admin_home_t:file { read write };
> > allow svirt_t pulseaudio_port_t:tcp_socket name_connect;
> > allow svirt_t svirt_tmpfs_t:file read;
> > allow svirt_t user_tmpfs_t:file read;
> > 
> > Since qemu(svirt_t) is not allowed these permissions, pulseaudio crashes 
> > and qemu dies.
> I don't see it crashing - when I run with a guest with a sound device
> attached, I see the AVC denials, and QEMU just carries on without a
> active sound backend AFAICT.

FYI I can now reproduce the problem and there's lots of things going on
here :-(

First, QEMU isn't crashing, libvirtd is killing it because it hangs.

It is hanging because pulseaudio can't startup, and a bug in pulseaudio
causes it to then get stuck on a condition variable wait that is never
notified. THis causes the whole QEMU I/O loop to hang.

Pulseaudio has this idea of a 'system instance' which the admin can start
to provide a permanently active daemon, thus avoiding the need to autostart.
This isn't setup to work at all in Fedora though, and there's no obvious
way to disable autostart either :-( In theory though, if we could get 
autostart to be disabled, then we could allow QEMU access to the shared
'system instance' of PulseAudio just by making the SELinux policy allow
connection to its UNIX domain socket in /var/run/. 

It still tries to create some junk in /root/ even when using the system
instance which it really needs to not do. That said it seems to be OK
if this stuff fails and still connects to the daemon.

> > I believe you need to run without sound if you are running as root.
> We can't disable sound unconditonally for root, because not everyone
> will be using SELinux so its still valid to allow sound cards. I think
> the focus has to be on stopping QEMU from crashing. It might actually
> be an SDL bug, rather than a QEMU bug, because I believe its SDL that
> is responsible for opening the sound devices.

I'm going to commit the following temporary patch to Fedora 11 rawhide
libvirt builds only, to disable sound cards when SELinux is active and
running as root. This will avoid the AVC denials, while we spend more
time trying to get PA 'system instance' to work better, without autostart

Index: src/qemu_conf.c
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.138
diff -u -p -r1.138 qemu_conf.c
--- src/qemu_conf.c	16 Mar 2009 13:54:26 -0000	1.138
+++ src/qemu_conf.c	17 Mar 2009 15:50:10 -0000
@@ -757,6 +757,20 @@ int qemudBuildCommandLine(virConnectPtr 
     char uuid[VIR_UUID_STRING_BUFLEN];
     char domid[50];
     char *pidfile;
+    int skipSound = 0;
+    if (driver->securityDriver &&
+        driver->securityDriver->name &&
+        STREQ(driver->securityDriver->name, "selinux") &&
+        getuid() == 0) {
+        static int soundWarned = 0; 
+        skipSound = 1;
+        if (vm->def->nsounds &&
+            !soundWarned) {
+            soundWarned = 1;
+            VIR_WARN0("Sound cards for VMs are disabled while SELinux security model is active");
+        }
+    }
@@ -1364,7 +1378,8 @@ int qemudBuildCommandLine(virConnectPtr 
     /* Add sound hardware */
-    if (vm->def->nsounds) {
+    if (vm->def->nsounds &&
+        !skipSound) {
         int size = 100;
         char *modstr;
         if (VIR_ALLOC_N(modstr, size+1) < 0)

|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the libvir-list mailing list