Description of problem: /dev/kvm has 600 permissions by default and must be changed to 666 in order for a libvirt stack to use it. The qemu-system-x86 rpm includes workarounds for making this happen: ``` [vagrant@f25vanilla sp]$ rpm -qf /lib/udev/rules.d/80-kvm.rules qemu-system-x86-2.7.1-2.fc25.x86_64 [vagrant@f25vanilla sp]$ cat /lib/udev/rules.d/80-kvm.rules KERNEL=="kvm", GROUP="kvm", MODE="0666" ``` as well as ``` [vagrant@f25vanilla sp]$ rpm -q --scripts qemu-system-x86 postinstall scriptlet (using /bin/sh): # Default /dev/kvm permissions are 660, we install a udev rule changing that # to 666. However trying to trigger the re-permissioning via udev has been # a neverending source of trouble, so we just force it with chmod. For # more info see: https://bugzilla.redhat.com/show_bug.cgi?id=950436 chmod --quiet 666 /dev/kvm || : ``` As more and more people start to containerize stuff running a libvirt stack inside a container will become more popular. In the scenario where libvirt is run inside a container the scriptlets the rpm delivers and the udev rules it delivers will be inside the container and won't actually have any effect on /dev/kvm on the host. This means either the admin of the host would have to change those permissions or the container will have to change them on startup every time. Would it be more reasonable to make the permissions on /dev/kvm default to 666 vs 600 (maybe by storing the rule in the udev package) so that we don't have to play musical chairs? There may be an argument for security that could be made here. I don't fully understand the implications so please educate me :). I'm aware that this is not a bug against qemu, but I opened it here because you guys are the best ones to know where to send it next, or to tell me to shut up and go home. Thanks
> There may be an argument for security that could be made here. I don't fully > understand the implications so please educate me I will just note that Debian defaults to 0660 + group kvm, which means people wanting KVM must add themselves to the kvm group. I had something of an argument with the Debian developer on this topic. In brief, his concern is security. You can read more here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640328 Having said all that, in Fedora we've set /dev/kvm to mode 0666 for years, albeit you have to install the qemu package to "request" that, but every desktop user will have qemu installed anyway, and no one understands that the mere action of installing qemu opens up permissions (even I didn't know until just now). So I think we should change the udev rules as you say.
(In reply to Richard W.M. Jones from comment #1) > > Having said all that, in Fedora we've set /dev/kvm to mode 0666 for > years, albeit you have to install the qemu package to "request" > that, but every desktop user will have qemu installed anyway, and > no one understands that the mere action of installing qemu opens up > permissions (even I didn't know until just now). So I think we > should change the udev rules as you say. Can you re-assign this BZ to the appropriate group so we can have that discussion in this ticket?
I think it's best to discuss this on Fedora devel list. Therefore I opened the following thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WTYWLEET4ZEHZIZTIJ7QDAOJ7JHOHHSA/
(In reply to Richard W.M. Jones from comment #3) > I think it's best to discuss this on Fedora devel list. Therefore > I opened the following thread: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/WTYWLEET4ZEHZIZTIJ7QDAOJ7JHOHHSA/ From this thread, Zbyszek said: > This applies to any system where kvm is to be used by unprivileged users > without qemu package being installed. It is possible to use kvm in this > way, e.g. by using self-compiled qemu, or some alternative or whatever. > So maybe we should move the rules for /dev/kvm to > /usr/lib/udev/rules.d/50-udev-default.rules. So reassigning to systemd. The rule content is: $ cat 80-kvm.rules KERNEL=="kvm", GROUP="kvm", MODE="0666" And the spec file also contains: getent group kvm >/dev/null || groupadd -g 36 -r kvm
I'll submit a PR upstream.
https://github.com/systemd/systemd/pull/5597
It took a while, but the systemd part is done (in rawhide). Reassigning to qemu, please remove the rule there.
I notice the systemd spec has: -Dkvm-access-mode=0666 but the systemd upstream configure seems to need --with-dev-kvm-mode=0666, so is the spec file right?
Good catch, is should be -Ddev-kvm-mode=... I restarted the build. (I'm a bit disappointed that meson does not throw an error: https://github.com/mesonbuild/meson/issues/2059)
I've queued this change in qemu rawhide spec, will be in the qemu-2.10.0-rc2 build (or later)
thanks all
Interestingly Fedora Rawhide on s390 ships with: # ll /dev/kvm crw-------. 1 root root 10, 232 Dec 5 08:28 /dev/kvm qemu 2:2.11.0-0.2.rc1.fc28 systemd-235-4.fc28.s390x It seems like this systemd is new enough, but yet it still has the wrong permissions. Not sure what's up.