> 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:
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
> 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 rules.d/ 40-qemu- system. rules{, .disabled} udev-acl{ ,.disabled} rules.d/ 40-qemu- system. rules{. disabled, } virtual/ misc/kvm
$ sudo mv /lib/udev/
$ sudo mv /lib/udev/
$ sudo modprobe kvm_intel
$ sudo cp /lib/udev/
$ udevadm trigger --sysname-match=kvm --verbose
/sys/devices/
$ 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?