Hi Garry, thanks for your reply. Q: what do you mean by "setting up a new storage context" in your last comment? A: the code was not only trying to connect to libvirtd, by tracking in gdb I found that it was also trying to itself do some actions that would make virt-aa-helper behave like the backend in libvirtd. So it would set up its own "context" that might differ from what libvirtd sees.
Q: why does the AppArmor security driver use a helper binary (virt-aa-helper)? A: libvirt by the nature of what it needs to do needs a lot of capabilities. Splitting that in two would allow for two different profiles. I think it was meant to allow the virt-aa-helper profile to allow more and later restrict the libvirtd profile a bit more (hasn't happened yet). And it was meant to deal with manipulating AppArmor. Also this was 11 years ago, so yes it might be worth to revisit (I had the same thoughts, and to admit keep forgetting why I considered it impossible the last time) As I mentioned above, I think the approach in your patch is wrong in the long run (causing too much other issues). But experimenting and discussing about it gave me some good alternative ideas. I'm waiting for Jamie to reply to my mail and then hopefully can give it a try on a different implementation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1677398 Title: Apparmor prevents using storage pools and hostdev networks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
