Comment 7 for bug 1103022

> This is where you've gone wrong in your experiment. The /dev/kvm perms will be correct because you've reloaded kvm_intel
after a (any) 40-qemu-system.rule existed.

Ah, thanks for pointing out!

I just noticed another problem which we might have overlooked here:

$ sudo rmmod kvm_intel kvm
$ sudo mv /lib/udev/rules.d/40-qemu-system.rules{,.disabled}
$ sudo mv /lib/udev/udev-acl{,.disabled}
$ sudo modprobe kvm_intel
$ sudo cp /lib/udev/rules.d/40-qemu-system.rules{.disabled,}
$ udevadm trigger --sysname-match=kvm --verbose
/sys/devices/virtual/misc/kvm
$ ls -l /dev/kvm
crw------- 1 root root 10, 232 Jan 30 07:21 /dev/kvm

i. e. triggering a change (or add) event does not actually apply the GROUP and MODE settings to /dev/kvm, it remains as root. This is without any udev-acl magic, and happens both with the current package rules as well as the simpler rules I tried above (without the := and RUN).

So that part of the postinst doesn't currently work as expected.

When I work around this by setting the permissions manually (as the postinst intends to do)

   sudo chgrp kvm /dev/kvm
   sudo chmod g+rw /dev/kvm

then running

  sudo /lib/udev/udev-acl.disabled -a change --device=/dev/kvm

seems to have the desired effect:

$ getfacl /dev/kvm
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:martin:rw-
group::rw-
mask::rw-
other::---

So may it be that this was a red herring, caused by the unexpected/wrong group and permissions of /dev/kvm after triggering the rule?