Hi Launchy Man,
and thanks for your report.
So to clarify you get an error like:
apparmor="DENIED" operation="file_receive" profile="libvirt-..."
name="/dev/vhost-net" comm="qemu-system-x86" requested_mask="rw"
denied_mask="rw"
The fix for this actually made it upstream in [1].
Since then the individual guest profile gets the rule "if needed".
That is even done with the default devices these days, so my guests always have
this:
grep vhost /etc/apparmor.d/libvirt/$(virsh dominfo xenial-test2 | awk
'/^Security label:/ {print $3}').files
/dev/vhost-net rw,
My test system had
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
</interface>
I wonder if this could be a timing issue - for example:
1. start a guest without any vhost needing device
(rule is not added intentionally)
2. later hot-add such a device
(error would be that it is missed to add the rule now)
To test that I started my guest without any network.
Now the guest profile has no vhost-net rule (as expected)
Then I added the userspace network like you (working, no rule change) and
removed it again.
$ virsh attach-interface --domain xenial-test2 --type network --source default
--mac "de:ad:be:ef:de:ad" --config --live
$ virsh detach-interface --domain xenial-test2 --type network --mac
"de:ad:be:ef:de:ad" --config --live
Note that on each of those actions as I expected I saw a trigger to reload the
profile on hot-add.
So we got:
[...] apparmor="STATUS" operation="profile_replace" [...]
name="libvirt-2359c3ff-6003-429a-b56e-bf55ec84203b//qemu_bridge_helper"
pid=7493 comm="apparmor_parser"
Note: the env obviously will have to be vhost-net capable or it will
silently fall back to non-vhost.
Next I attached the mode virtio device like you did (destroyed and re-spawned
the guest before that to be clean):
$ virsh attach-interface --domain xenial-test2 --type network --source default
--model virtio --mac "de:ad:be:ef:de:ad" --config --live
error: Failed to attach interface
error: internal error: unable to execute QEMU command 'getfd': No file
descriptor supplied via SCM_RIGHTS
So far confirmed, but great Idea where to intercept at the right time - I'd
have expected that the profile reload would load a new profile with the needed
rule added.
OTOH as soon as you have any vhost-net device on the normal start (most common)
it will work.
So severity is low.
[1]:
https://libvirt.org/git/?p=libvirt.git;a=commit;h=c7abe7448c746cf0e3a6b7fab80e083afba5d5ae
** Changed in: libvirt (Ubuntu)
Status: New => Confirmed
** Changed in: libvirt (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1739674
Title:
virsh Fails at Hot Plugging Network Device with model virtio
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1739674/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
