Problem with a disk device of type 'volume'

[Frédéric Lespez]

Le 18/08/2022 à 14:48, Peter Krempa a écrit :
> Hi,
> 
> I'm fairly certain that the above is because of Apparmor. Specifically
> the apparmor labelling code does not translate the pool/volume name to
> the path to the image, while for other security drivers we use the
> existing definition and thus do translate it.
> 
> I'm not familiar enough with apparmor to point you to how to configure
> logging properly, though.
> 
> The issue originates from the fact that the apparmor driver uses a
> helper process to setup the labelling and the helper process itself is
> not able to access libvirt's storage driver and thus unable to do the
> translation.
> 
> I'll try to think about a possibility to pass the path though.
> 
Hi Peter,

I was about to answer you that I made tests exonerating AppArmor.  For 
example, I tweaked the /etc/apparmor.d/libvirt/TEMPLATE.qemu to 
workaround the fact that virt-aa-helper cannot dynamically generate 
correct profiles when using pool/volume names (since it only has the 
domain's XML definition, it cannot generate correct rules without having 
the storage pool's XML definition).

But I decided to do some tests again, since I made these at the 
beginning of my research.

An effectively AppArmor is the culprit !
I discovered that:
  - you need to reboot between tests (reloading profiles - or AppArmor 
itself without a reboot is not sufficient even if the docs I have read 
say it is not needed)
  - Apparmor can do "something" without logging a message (at least with 
the default configuration in Debian 11).

I will do more tests in order to pinpoint the precise cause and report 
my findings.

Thanks a lot for drawing my attention again to AppArmor.
It was driving me nuts !

Regards,
Fred