libusb as used by qemu needs to read data from /run/udev/data/ about usb devices. That is read once on the first initialization of libusb_init by qemu. Therefore generating just the device we need would not be sufficient as another hotplug later can need another device which would fail as the data is no more re-read at this point. But we can restrict the paths very much to just the major number of potential usb devices which will make it match approximately the detail that e.g. an lsusb -v would reveal - that is much safer than the "/run/udev/data/* r" blanket many users are using now as a workaround. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> --- examples/apparmor/libvirt-qemu | 3 +++ 1 file changed, 3 insertions(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index dcfb1a5..b341e31 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -29,6 +29,9 @@ # For hostdev access. The actual devices will be added dynamically /sys/bus/usb/devices/ r, /sys/devices/**/usb[0-9]*/** r, + # libusb needs udev data about usb devices (~equal to content of lsusb -v) + /run/udev/data/c16[6,7]* r, + /run/udev/data/c18[0,8,9]* r, # WARNING: this gives the guest direct access to host hardware and specific # portions of shared memory. This is required for sound using ALSA with kvm, -- 2.7.4 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
