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
