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

Daniel J Walsh dwalsh at redhat.com
Tue Mar 17 16:49:18 UTC 2009


On 03/17/2009 11:52 AM, Daniel P. Berrange wrote:
> 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");
> +        }
> +    }
>
>       uname_normalize(&ut);
>
> @@ -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)
>
>
Looks good to me.




More information about the libvir-list mailing list