Comment 12 for bug 1724441
Revision history for this message
| Christian Ehrhardt (paelzer) wrote | #12 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
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-
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-
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:/
[2]: https:/
[3]: https:/