Hi Costinel and Robert, sorry that we all had dropped the ball on this for a while - it was mostly by the lack of being able to reproduce it anywhere else that stalled this.
... [imagine a long useless trip trying to re-trigger it, but details of that would not help] ... Much better I found that it was already found, discussed and eventually fixed [1]. This is in libvirt 7.5 and later and thereby released in Ubuntu 21.04 and later. Since we didn't yet find a functional issue if that is lacking (other than the stray log entries), I'd keep it at that (fixed in later relases, can be worked around via config files in older releases). If either of you (or anyone else) spots a functional issue that gets resolved by adding those we can re-consider an SRU. In that case please speak up here what use-case is blocked by not having those allowed. If it outweights the risk of adding that we can SRU this changed default config. If not, for anyone interested, the workaround for an admin would be to add the rules [1] added in your local override `/etc/apparmor.d/local/usr.sbin.libvirtd`. --- P.S. Along that I also found why (among other reasons) that those messages might sometimes be relates to a scsi setup. I've found that (the above is the rule for the daemon) also guests might run into trouble with that if using <disk type='block' device='lun' rawio='yes'> as outlined in [2]. That might be a real issue, but would be another bug and needs upstream implementation in virt-aa-helper and libvirtd to add the rule accordingly for that guest configuration. But OTOH since using that feature also includes "domain have to be executed with root privileges" and therefore isn't very safe we would not want to make that easier. So for the few who want that very special and less safe subcase, consider adding the rule to your local guest override in /etc/apparmor.d/local/abstractions/libvirt-qemu --- P.P.S and the message we see on service start might despite all the confusion be capability checking on service startup. While I didn't see why it would happen exactly *sometimes* for an undefined subset of sometimes. I can see that the probing of features when the daemon starts will include sys_rawio since it is meant to eable/drop that for lxc based guests. There are also pool-capabilities, but while it would seem reasonable I couldn't quickly find sys_rawio there. But if the usage for sys_rawio is really only unsafe guest disks and lxc caps, then (again) I think this isn't something we want to make much easier to use as it is less safe (and for lxc usage LXD is very much recommended over libvirt anyway). [1]: https://gitlab.com/libvirt/libvirt/-/commit/4f2811eb816ed1da215b86778dfcf483917666a1 [2]: https://gitlab.com/libvirt/libvirt/-/commit/397e6a705b98a89c0cc6ca74db9648cf8697e214 [3]: ** Also affects: libvirt (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: libvirt (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: libvirt (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: libvirt (Ubuntu) Status: Incomplete => Fix Released ** Changed in: libvirt (Ubuntu Impish) Status: New => Fix Released ** Changed in: libvirt (Ubuntu Hirsute) Status: New => Incomplete ** Changed in: libvirt (Ubuntu Focal) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1881969 Title: apparmor profile for libvirtd/libvirt-daemon needs fixing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1881969/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
