Please make /dev/kvm world-accessible in 45-qemu-kvm.rules

[Geoffrey Thomas]

It would be nice if /dev/kvm were world-accessible, so that unprivileged users could use hardware virtualization features without needing to be added to the kvm group in advance by a system administrator.

Currently the following rule is in place on Natty:

w-a-thornhump-iii:~ geofft$ less /lib/udev/rules.d/45-qemu-kvm.rules
KERNEL=="kvm", GROUP="kvm", MODE="0660"

I'd like that to be changed to mode 0666. Fedora has decided that this is okay in terms of security, and that this is a useful change to be made. On my Fedora 15 box, the following rule is in place:

busy-beaver:/etc/udev/rules.d geofft$ less 80-kvm.rules
KERNEL=="kvm", GROUP="kvm", MODE="0666"

(I don't understand why it's in /etc, but it is in fact packaged in qemu-system-x86-0.14.0-7.)

See also "We have already reserved a group called 'kvm' in the setup package, so no need for yet another called 'vm'. The /dev/kvm should be chgrp kvm by default. That said I agree with Mark that it'd be desirable to also make it possible to just any normal user access to /dev/kvm out of the box, so libvirt's per-user qemu:///session connection can be used" from https://bugzilla.redhat.com/show_bug.cgi?id=481260 .

I'm working on a software package that would benefit from unprivileged remote users being able to access kvm, so this change would be beneficial to me. It sounds from the above text that this would also make using libvirt easier.

[Soren Hansen (soren)]

The reasons for limiting access to /dev/kvm expired years ago. There's
no longer any particular reason to not make it world writable.

--
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

[Jamie Strandboge (jdstrand)]

What specifically were these reasons? When did they no longer become a concern and why?

[Soren Hansen (soren)]

The problem back then was that anyone with access to /dev/kvm could allocate an arbitrary amount of memory that could not be swapped out. Dead-easy DoS. Since... I don't remember when, years ago at least, memory used by kvm can be swapped out like all other memory, so it's in terms of DoS by memory allocation, it's no more dangerous than giving people access to run malloc. :)

You're also giving them access to execute certain cpu instructions they otherwise wouldn't be able to, but -- modulo whatever security bugs there might be, of course -- these aren't sensitive instructions (in the way they're exposed through the kvm interface, that is). KVM was designed to be safe to run this way.