Re: Problem with a disk device of type 'volume'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Le 18/08/2022 à 14:48, Peter Krempa a écrit :

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

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 !


[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux