> 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?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1103022
Title:
70-udev-acl.rules needs to put g+rw on /dev/kvm
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1103022/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
