On Fri, Jul 05, 2024 at 12:38:36PM GMT, Christian Ehrhardt wrote:
That is due to the check for valid_path having /usr/share/OVMF/ in restricted_rw and therefore blocking this. Now the question is, was this meant to allow using the system files RW - then I think it is rightfully blocked. Instead I'm going to assume this was meant for separate files.
# TEST ONLY - DO NOT DO THIS $ cp /usr/share/OVMF/OVMF_CODE_4M.fd /opt/OVMF_CODE_4M.fd $ chmod 666 /opt/OVMF_CODE_4M.fd
root@o:~# virsh dumpxml testdomain | grep OVMF; uuid=$(virsh domuuid testdomain); cat /etc/apparmor.d/libvirt/libvirt-${uuid}.files | grep OVM <loader readonly='no' type='pflash'>/opt/OVMF_CODE_4M.fd</loader> "/opt/OVMF_CODE_4M.fd" rwk,
So we can see the code achieves what it is intended to do while not regressing the former flow.
But it can not be used on the normal paths, that is probably good to avoid accidentally overwriting these.
We definitely don't want the shared CODE files to be used in read/write mode, as that would certainly cause corruption. In fact, I would have expected such a request on the user's part to be outright rejected by libvirt, but when I tried I realized that wasn't the case, at least in some scenarios. I've just posted some patches[1] that should improve the situation.
But I think along the patch we should hear a little bit more about the use case to ensure that it has a practical use?
@Miroslav: how exactly would you make use of that now?
Yes, it would be nice to get confirmation. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/2NR3N... -- Andrea Bolognani / Red Hat / Virtualization