I've written a quick patch that seems to fix the storage pool side of this issue, at least for dir/fs like pool types. It does connect to the libvirtd socket; I saw that there was some concern with that approach earlier, but this solution didn't require any changes to virt-aa-helper's calling conventions. Are we still opposed to having virt-aa-helper connect to libvirtd?
A couple notes about what is needed to use this, which might be obvious to those more experienced with libvirtd than myself:
* You may need to use a common file extension for the AppArmor profile to allow virt-aa-helper itself to inspect your image files.
* If you also need the AppArmor profile to allow read access to a backing file chain, your domain will need to have a driver element in the disk device definition, with the type attribute set appropriately.
I've written a quick patch that seems to fix the storage pool side of this issue, at least for dir/fs like pool types. It does connect to the libvirtd socket; I saw that there was some concern with that approach earlier, but this solution didn't require any changes to virt-aa-helper's calling conventions. Are we still opposed to having virt-aa-helper connect to libvirtd?
A couple notes about what is needed to use this, which might be obvious to those more experienced with libvirtd than myself:
* You may need to use a common file extension for the AppArmor profile to allow virt-aa-helper itself to inspect your image files.
* If you also need the AppArmor profile to allow read access to a backing file chain, your domain will need to have a driver element in the disk device definition, with the type attribute set appropriately.