Hi Michael, thank you for the discussion, no need to apologize - I can see your troubles and want to help. But lets dissect the different aspects of it.
TL;DR: - path in qemu.conf should not matter - need to set-uid manually is wanted for security reasons - apparmor fixes exist, please chime in on bug 1754871 [2] if you think 18.04 should get that 1. apparmor to be able to use ubuntu-bridge-helper. I pushed a change upstream [3] for bug 1754871 already, that is similar to yours but more limited to what you actually need to get it working. Although this was done at a low prio and my intention was to only pick this up with Ubuntu 18.10 and I was not yet planning to backport the fix. The reason is that it is a config file change everybody can do and the number of use cases depending on it was considered very low. Although I think I could be convinced this is used more often than I thought to push the fix to the apparmor profile at least to all >= Ubuntu 18.04. I'd ask you to post on bug 1754871 if you really think we should make the apparmor change generally available. Since 18.04 is an LTS I think that would be fair. 2. set-uid qemu-bridge-helper is a bit of an ugly case, qemu.bridge-helper is considered "unwanted but sometimes needed" at best I feel. In bug 1754871 we outlined and referred to a bunch of reasons why it won'd be delivered as set-uid (not doing again here). Therefore you'd still need to add the setuid as it was considered to insecure to deliver it with setuid. 3. path in qemu.conf I think changing the path for qemu-bridge-helper in qemu.conf to be correct should be "ok", but I actually think it is not needed. At build time libvirt detects where qemu-bridge-helper is on a system (as it might differ per distribution) and it does: ... checking for sys/inotify.h... yes checking for qemu-bridge-helper... /usr/lib/qemu/qemu-bridge-helper checking for xen_vm_start in -lxenserver... no ... So if nothing is set in the config it should use this path. The path you see commented out in the config file is just an example and that way because of [1] is what it is upstream. Summary: - I think #1 is covered by the bug I referred. - #2 is intentionally staying the way it is. - And #3 should not be an issue - it would be great if you can double-check that. If you agree we can set this bug here back to invalid and you can chime in on [2] to push this to Bionic as well. [1]: https://libvirt.org/git/?p=libvirt.git;a=blob_plain;f=src/qemu/qemu.conf;hb=HEAD [2]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1754871 [3]: https://libvirt.org/git/?p=libvirt.git;a=commit;h=6a9bdf3f25fb3941d587b3f2877b36e4412d6762 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1724441 Title: No external network access for VMs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-boxes/+bug/1724441/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
