Comment 35 for bug 1677398

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.